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EXECUTIVE SUMMARY 


This report documents the Systems Engineering research on a Concept of 
Operations (CONOPS) for interoperability between the MQ-8 Fire Scout Vertical 
Takeoff Unmanned Air Vehicle (VTUAV) and the MH-60 Seahawk Multi Mission 
Helicopter, as they are intended to be deployed off the Littoral Combat Ship (LCS). This 
research provides a foundation for defining an integrated System of Systems (SOS) that 
with further study, may support a future acquisition program designed to enhance 
interoperability between the MH-60 and Fire Scout whenever they are deployed together. 

This project started with the goal of improving interoperability between the Fire 
Scout and the MH-60 helicopter as they are planned to be deployed aboard US Navy 
vessels. The Chief of Naval Operations (CNO) mandated increased use of Unmanned 
Vehicles in an effort to minimize quantity and risk to aircraft operations and personnel. 
Improving interoperability has the potential to increase mission success and reduce 
manpower requirements by more effectively prosecuting assigned missions. Currently, 
the Fire Scout performs Intelligence, Surveillance, and Reconnaissance missions, 
whereas the MH-60 helicopter performs a wider variety of mission, including, but not 
limited to, Anti Surface Warfare (ASUW), Logistics, Anti-Mine Countermeasures 
(AMCM), and Special Warfare missions. Fire Scout has been deployed during test 
mission with Helicopter Squadron HSL-42, where it was flown as a stand-alone unit (i.e. 
not interoperating with the MH-60) during test and evaluation. 

The project team interviewed requirements officers from the CNO and the 
Commander Naval Air Forces staff organizations and determined that a significant area 
of interest was the protection of a High Value Asset (HVA) from a small boat swarm 
attack while transiting a choke point, such as the Straits of Hormuz, where threats could 
be intermingled with commercial shipping and pleasure craft. The newly-commissioned 
LCS was chosen as the launch platform for the MH-60 and Fire Scout, as it is currently 
scheduled to deploy with these aircraft in the 2012 timeframe. With this information, we 
created a Concept of Operations, a Mission Scenario, and an Architecture that defined the 
interface between the LCS, Fire Scout, and MH-60 helicopter when performing the 
ASUW mission to protect the HVA from a small boat swarm attack. 
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The architecture and interface definitions led to analysis of the communications 
links between the aircraft and LCS as currently configured, and defined a “decision path” 
required to support the mission activities of detection, classification, and identification of 
targets in the operational area. This “decision path” was defined to support prosecution 
of a target identified as a threat. The research stopped after the identification phase; the 
engagement phase of the mission and target prosecution was beyond the scope of the 
project and modeling approach, and remains for follow-on study. The project adopted 
the concept “more”, “better”, and “faster” information provided to decision makers 
would minimize the time required to detect, classify, and identify the threats, leaving the 
most time available for prosecuting those threats as necessary. 

The research detennined three separate opportunities existed to improve the 
decision-making time. These opportunities were subsequently defined as SOS 
alternatives. First, the Fire Scout sensor data (video) was data-linked to the Fire Scout 
Control Station (FSCS) on the LCS. The FSCS is not currently connected to the Combat 
Information Center (CIC) on the LCS, so there is no direct way to get the Fire Scout 
sensor data to the decision makers in CIC. Alternative 1 addressed improvements to the 
LCS to distribute data within the LCS, providing “more” and “faster” data to the decision 
makers. 

Another limiting factor in the communication chain was the use of only one 
Tactical Common Data Link (TCLD) channel on LCS, even though there are two 
channels available. The MH-60R helicopter had a “Hawk Link” data link that is 
compatible with the standard Common Data Link (CDL) message structure, whereas the 
Fire Scout was equipped with TCDL. Currently, only one aircraft can send sensor data to 
the LCS down the TCDL data link. (Further, only one of the LCS ship configurations has 
two data link antennas. The other has only one antenna, and thus is only capable of a 
half-duplex link between the two aircraft.) Given the opportunity to employ existing data 
links, Alternative 2 addressed opening up both TCDL channels so that sensor data from 
both aircraft can be monitored simultaneously. Opening up both TCDL channels on the 
LCS again provided “more” and “faster” data to the decision makers. Also, since the 
MH-60R is currently the only MH-60 in the inventory with a CDL-compatible data link 
and is planned to deploy from the LCS, it became a focal point for our analyses. 


7 



The third and final alternative investigated was to provide Fire Scout sensor data 
to the MH-60 helicopter to support sensor fusion, and to provide control of the Fire Scout 
sensor system by the MH-60. This approach would allow the MH-60 the capability to 
merge Fire Scout sensor data with on-aircraft data, and provide a more complete picture 
for making tactical decisions, but it would require integration of the Fire Scout and MH- 
60 via data li nk s. Potential implementation, for example may entail TCDL data li nk 
onboard the MH-60R to accommodate reception of the Fire Scout sensor data, re¬ 
transmission of that data to the LCS, or fusion of the Fire Scout data with MH-60R data 
for transmission to the LCS. It would also necessitate installation of FSCS components 
and applications on the MH-60R for control of the sensor suite. This approach provided 
“more”, “better”, and “faster” data to the decision makers, and also allowed the Fire 
Scout and MH-60 to work together when prosecuting a threat by using cooperative 
tactics. 

The project employed both an Excel model and the Naval Simulation System 
(NSS) model to simulate the aforementioned alternatives, using time estimates for the 
steps in the decision chain. The SOS baseline performance was modeled first for 
comparison with each of the three alternatives. The Excel model indicated that 
Alternative 3 would provide the greatest improvement on the key metric, “Time to 
Identify.” Interestingly, the NSS model did not yield the same results. The differences in 
outcomes was analyzed and led to the conclusion that the NSS model was not created 
with the necessary fidelity to accurately capture the parameters of the mission scenario. 
The finding that warfare analysis models must be purpose-built for systems engineering 
analysis, by carefully defining the format and content of input and output parameters for 
the systems, scenarios and architectures, is an important lesson learned. With additional 
time (and funding), the NSS model could be modified to better reflect the system 
engineering concerns and yield more informative results. For example, the NSS model 
should be redesigned to support combining the effects of implementing more than one 
alternative. 

To ensure the research and analysis of alternatives activities supported 
stakeholder interests and decision-making, the project created a Work Breakdown 
Structure and defined the tasks required to implement each of the alternatives as a stand- 
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alone effort. A parametric cost estimates was performed to create a “bang for the buck” 
assessment of the alternative. A high-level risk assessment was performed to categorize 
and quantify risks associated with each alternative. Collectively, the research addressed 
effectiveness of alternatives and provided a framework for assessment of cost, risk and 
performance impacts. 

The project concluded that Alternative 1, linking the FSCS and CIC directly via 
data link onboard the LCS would provide the best “bang for the buck” to improve 
interoperability and overall mission effectiveness. This alternative was the least complex 
in terms of physical and functional integration. It also, therefore, brought the least risk 
and cost to a solution for the original requirements. Within the limits of the modeling, 
the NSS results indicated that Alternative 2, enabling the second TCDL channel on the 
LCS ship, would provide the greatest effectiveness. Taken together, the research 
provided systems engineering insight that an additive, incremental approach for 
implementing the three leading alternatives may be feasible and the optimal way to meet 
the requirements while evolving manning concepts, tactics and training for SOS 
operations with manned and unmanned assets. Each alternative could be pursued 
separately, but the combination of Alternative 1 and 2 may address not only the mission 
in focus, LCS defense against a swarm of small boats, but also provide a robust solution 
for improved interoperability and effectiveness across multiple missions. Modeling and 
analysis of cumulative effects may confirm that it would be more beneficial to implement 
Alternative 1 prior to or in conjunction with Alternative 2, as opposed to only Alternative 
2. The same is true for the combined effects associated with Alternatives 1 and 3. 
Alternative 3 presented the highest cost and technical risk, but could also ultimately 
achieve the greatest interoperability improvement as mission planning methods and 
tactics are developed. 

Currently, there is very little operational experience with the Fire Scout operating 
from a small ship such as the LCS, but as more experience is gained, greater utilization of 
the Fire Scout capabilities as a stand-alone aircraft, and eventually as an interoperable 
asset, will be achieved. This will open the doors for development of new missions and 
tactics. The foundation that has been laid by this research supports development of these 
future capabilities. 
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I. INTRODUCTION 


A. BACKGROUND 

The Chief of Naval Operations (CNO) has stated the objective of achieving a 
predominantly unmanned force structure by 2030 fl l More recently, CNO directed 
development of an integrated vision for unmanned systems with legacy, manned force 
structure To counter emerging threats and achieve enhanced war fighting capability, 
System of Systems (SOS) comprised of legacy systems augmented by advanced 
technology and concepts are being explored to detennine potential “value-added.” In 
response, Naval Air System Command (NAVAIR) and the Program Executive Office 
(PEO) have endorsed the need to assess formally integration opportunities by mission 
area capability as a means of furthering manned and unmanned system integration and 
filling capability gaps for the naval force structure. 

1. Purpose 

This research focused on defining alternatives for enhanced mission effectiveness 
through increased interoperability and integration of the MQ-8 Fire Scout and MH-60 
Seahawk variants (MH-60R, MH-60S). Because the Fire Scout and the Seahawk have 
already demonstrated high potential for delivering enhanced capability when operating 
synergistically, Navy leadership expressed interest in the integration of these systems so 
that the MH-60 would be able to monitor data gathered by the Fire Scout and potentially 
take control of the Air Vehicle (AV) and sensors to support emergent mission 
requirements 

The MH-60 Multi Mission Helicopter is deployed aboard any air-capable frigate, 
destroyer, cruiser, fast combat support ship, amphibious assault ship, or aircraft carrier. 
The Fire Scout Vertical Take-off Unmanned Air Vehicle (VTUAV) is currently being 
introduced into the US Navy Fleet to deploy on any ship where an MH-60 helicopter 
deploys, including aircraft carriers, frigates, destroyers, and the Fittoral Combat Ship 
(FCS). The roles for the Fire Scout are still being detennined, however, its current suite 
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of mission equipment enables the Fire Scout perfonn the Intelligence, Surveillance and 
Reconnaissance (ISR) mission to detect and monitor potential threats to the battle group 
contingent. Both the Fire Scout and MH-60 will be integrated on both types of LCS, 
enabling expansion of capabilities for Anti Surface Warfare (ASUW), Anti Submarine 
Warfare (ASW), and Airborne Mine Countermeasures (AMCM) |A missions. 

Manpower and helicopter requirements affect the ability to support long-term 
coverage, so the use of Unmanned Aerial Vehicles (UAV) has come to the forefront as a 
means to increase coverage and to minimize the impact on personnel and manned 
aircraft. This research addresses the potential mission enhancements that can be derived 
from using manned and unmanned aircraft in concert to increase operational coverage 
area, time on station, and Situational Awareness (SA) for decision makers. The project 
highlights the tactical decision-making process and individual platform capability 
enhancements that will improve the ASUW war fighting effectiveness in a given 
scenario. The project assessment applies the Systems Engineering Design Process 
(SEDP) with emphasis on the early phases of Needs Analysis, Requirements Definition, 
and Analysis of Alternatives, leading to recommendations for enhancements or solutions 
that can be accomplished based on the existing Programs of Record. 

2. Project Mission Focus 

Although the Fire Scout, MH-60 and LCS are multi-mission capable systems, the 
project focused on the ASUW mission area and further narrowed the scope of 
investigation to the small-boat swann threat (SWARM). This focus was specifically 
requested by the MH-60 and Fire Scout program managers and resource sponsors to 
provide an option for filling a known gap in current operational capability ^ 7| . ASUW, a 
Naval Surface warfare (SUW) mission area, is defined as, “...That portion of maritime 
warfare in which operations are conducted to destroy or neutralize enemy naval surface 
forces and merchant vessels [8] . “ 

The ASUW mission is a key capability of Sea Power 21 and specifically of the 
Sea Shield pillar. Sea Power 21 is the Navy’s Strategic Vision for the 21 st century. Sea 
Power 21 aims to transfonn the naval force through innovative concepts and technologies 
that integrate sea, land, air, space and cyberspace. The goal is to use “revolutionary 


28 



information superiority and dispersed, networked force capabilities to deliver 
unprecedented offensive power, defensive assurance and operational independence to 
Joint Force Commanders.” Sea Power 21 relies on three pillars - Sea Strike, Sea Shield, 
Sea Base - and the FORCEnet integrating construct. Sea Shield is the Naval Capability 
at the center of this project. Sea Shield is focused on “.. .protection of national interests 
with layered global defensive power based on control of the seas, forward presence and 
networked intelligence” taking traditional naval unit and task force defense of the Fleet 
and sea lines of communication to a new level for sea-based theater and strategic defense 
[9] . A representation of the strategic vision and project operational context is provided by 
Figure 1. 


SEA POWER 21 
Sea Shield 



Sea Strike 


Sea Basing 


NT A 1.5.2 Conduct Maritime Superiority 

To establish and maintain superiority in the 
operating area by engaging all hostile air, 
surface and subsurface threats at maximum 
range consistent with the rules of engagement 
and approved tactics. 


NTA 1.5.2.1 Conduct Surface Warfare 

To establish and maintain surface superiority 
in the assigned operating area through 
employment of surface ships, submarines and 
aircraft. 


Joint Doctrine: JP-1, 3-0, 3-02, 3-04.1, 3-07, 

Navy Doctrine: NDP 1, NWP 3-20.3, 3-20.4, 3-20.6 Series, 3-56, 


NWP 3-20 

1 January 2007 

Navy Surface 
Warfare Manual 
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FIX 
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TARGET 



NTTP 3.60-1 SUW Kill Chain 


Figure 1: Context for System and SOS ASUW - SUW System / SOS Solutions 

Sea Shield capabilities can be defined according to the Universal Navy Task List 
(UNTL) l - l0 \ “... the common language that commanders can use to document their 
command war fighting requirements as Joint Mission Essential Tasks. The UNTL is a 
single source document that combines the Universal Joint Task List (UJTL, Joint 
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Doctrine) with the Navy Tactical Task List (NTTL),” the commander’s reference for 
strategic, operational and tactical activities and associated metrics for planning, training 
and readiness assessment [11] . The above figure shows the relationship between Sea 
Power 21 and the NTTL Navy Tactical Activities (NTA) for Surface Warfare (SUW). 
The Navy Warfare Publication 3-20 is the Surface Warfare Manual prescribed doctrine 
and li nk s strategic to operational tactics, techniques and procedures to meet mission 
objectives [12 l The manual provides a “Kill Chain” sequence of events from a Systems 
Engineering viewpoint. It represents the functional flow of work that the project 
alternative solutions for ASUW must accomplish, defining the SOS purpose. Taken 
together, this figure lays out the high level operational need and mission capability 
required by the project stakeholders for which project alternatives are defined. 


3. Project Trade space 


The project specifically explored the available trade space for the Fire Scout, MH- 
60 and LCS to share data between platforms as an SOS and achieve a distributed “kill 
chain” to address threats and targets in contested environments with greater accuracy and 
decreased timelines. This trade space was predefined by the existing platform 
configurations of these three contributing systems. Figure 2 provides an overview of the 
current and planned ASUW capabilities provided by the MH-60 series and Fire Scout. 



Capability (O: 

•Force Protection Multiplier 
•Sensor (FL1R) 

•Targeting 

•Comm. (V/UHF & SATCOM) 
Mission Scenario (MS): 

•Long Dwell Surveillance 
•SAR Search 
•Mine Warfare 
Future: 

•Data Relay (C) 

•ASuW Large Area Surveillance (MS) 
•ASuW Kill 1MS1 


Enhancements 


Capability (Cl: 

•ASUW' Detect 
•ASUW Track 
•ASUW ID 
•Maintain Common 
Operating Picture 

Mission Scenarios (MS): 

•ASUW Search 
•Surveillance 
•Communication Relay 



S/M/H/H-60B, H, & S 


Capability fC): 

*AS U W Detect 
•ASuW Track 
•A SuW Classify 
•ASuW Kill 
Mission Scenarios (MSI: 

•Logistics 

•Search and Rescue 
•ASuW' Search 


Figure 2: ASUW Capabilities and Mission Scenario Enhancements 
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The core mission capability resides with the MH-60 for the depicted Detect, 
Track, Classify and Kill activities. The Fire Scout is a “force multiplier” that augments 
the Detect and Track activities through search and long dwell surveillance using the 
onboard Forward Looking Infra-Red (FLIR) sensor. The enhancements listed in the 
center of the figure identify the benefits anticipated from integrating these two airborne 
assets. Using the Fire Scout “on a tether” from the MH-60 expands the search and 
surveillance area. Persistence aids maintenance of a Common Operating Tactical Picture 
(COTP) across crews and platforms. Integration of these platforms aims to achieve the 
desired enhancements for detection, tracking and identification through the synergistic 
effects of increased range and time on station. 

4. Project Context Diagram and Operational View 


As part of the SE process adopted for design of SOS alternatives, the project first defined 
the operational concept and context, including the boundary between the solution system 
trade space and the external environment [13 l Figure 3 presents a conceptual, high-level 
Operational View (OV-1) of the MH-60 and Fire Scout in the ASUW role of protection 
of High Value Assets (HVAs). The OV was developed to guide the requirements 
definition and analysis activities. The boundary that defines the trade space for SOS 
alternatives to be addressed by the project is depicted as a red oval in the figure. 
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Figure 3: MH60/Fire Scout Integration Operational View 
Within the boundary line, the MH-60, Fire Scout and LCS are the key assets for 
defining alternatives. The diagram also includes real-world capabilities that are not part 
of the project, but may impact context of any proposed SOS solution. For example, 
satellite communications and communications between the Aircraft Carrier (CV) and 
helicopter, as the MH-60 may be based on the LCS or the carrier. As part of coordinated 
operations with the Carrier Air Wing (CVW), the E-2 Hawkeye Airborne Early 
Warning/Airborne Command and Control aircraft is depicted. The E-2 also 
communicates with the F/A-18 Hornet Strike Fighter. Ashore, ground forces are depicted 
as supported units. The Fire Scout could be based and originate from an ashore unit, as 
well as the LCS. The CV, CVW and ground forces were not addressed within the scope 
of the project, but integration and interoperability within this context may impact 
acceptance of any SOS solution. 

The OV-1 supports a high level description of the activities and interactions among 
the platforms and systems employed for ASUW. This information establishes the basis 
for assigning mission tasks and roles, allocating functionality and defining information 
exchanges across the SOS. The following example is one of many that could be derived 
from the OV-1. 

1. MH-60 performs Surface Search. 

2. Fire Scout (FS) performs ISR, extending the area of coverage beyond the MH-60. 

3. FS Sensors detect possible Hostile Forces (HF), beyond range for FS link to LCS 
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4. MH-60 monitors the FS sensor data 

5. LCS directs MH-60 to relay FS sensor data as FS is sent closer to HF 

6. FS relocates and transmits sensor data to MH-60 

7. MH-60 monitors, fuses, and relays sensor data to LCS 

8. LCS verifies HF demonstrates hostile intent 

9. LCS requests MH-60 to send fused data to Decision Maker 

10. Decision Maker calls for Strike action and notifies LCS and MH-60 

11. MH-60 relays sensor data to E-2, which calls for Air Support 

12. E-2 sends sensor data to Strike Aircraft and calls for Strike 

13. Strike Aircraft rolls in, receiving constant updates from FS and or E-2 

14. FS remains on-station to continue ISR and perform BDA 

B. GOALS 


The goals of the Fire Scout - MH-60 interoperability project were to perfonn the 
SE tasks required to define mission functionality and activities, system preliminary 
design, analysis of alternatives, and planning for the development and test of an 
integrated set of solutions that supports a Fire Scout/MH-60 joint ASUW mission. An 
architecture was developed based on Stakeholder input and project scope definition based 
on existing system capabilities, which culminated in a draft Concept of Operations 
(CONOPS). Key Perfonnance Parameters (KPP) and Measures of Effectiveness (MOE) 
were defined, and Modeling and Analysis (M&A) was used to characterize SOS 
effectiveness and quantify performance based on the CONOPS. Trade studies between 
platforms, installed interfaces, equipment and functionality were developed based on 
mission scenarios associated with the CONOPS and informed by Stakeholder feedback. 
The project therefore includes the necessary tasking to define and plan for the Materiel 
Solution Analysis Phase and the Technology Development Phase to initiate an 
Incremental Acquisition Strategy for solutions that enhance the current ASUW mission 
set. This report provides the project cycle with control gates and artifacts, including SE 
plans and processes, applicable phases, and risk, cost, and performance analyses as 
deliverables. 
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C. SYSTEM ENGINEERING PROCESS 


The Systems Engineering Development Plan (SEDP) used during the Project is a 
combination of the standard "V" model and a Spiral-to-Circle model 1 ' 5| . A hybrid 
approach was chosen to provide a process flow tailored to the unique challenges of the 
project. The "V" model, shown below in Figure 4, was used as a blueprint for SE 
architecting and design activities early in the project development. 

There are no clearly defined requirements for the proposed SOS, as would 
typically be formally defined in an ICD by the Joint Capability Integration and 
Development System (JCIDS) process [16] . Each of the existing ASUW technical 
solutions was designed, developed and acquired as a separate and independent program 
in response to documented requirements. The proposed, integrated SOS solutions, 
however, will need to be defined, analyzed and documented as requirements for the same 
capability that may bring benefits in operational utility and effectiveness. The “V” model 
provided a straightforward means of defining the SOS as a unified, large-scale system to 
proscribe the integrated functionality to be achieved primarily through data-level 
communication and interoperability. 



Figure 4: Systems Engineering "V" Process Model 
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Based on the V model, the initial problem definition led to the development of 
research questions that were presented to the identified Stakeholders to begin design 
process. The path down the left side of the V model included the following SE activities. 

1. Define the Problem 

2. Define Stakeholders 

3. Define mission scenarios 

4. Define communication and interface capabilities 

5. Elicit, collect and rank requirements 

6. Iterate requirements with the Stakeholders 

7. Architect a method to satisfy the requirements 

8. Evaluate alternatives that support the architecture based on cost, 
schedule, technical perfonnance, and risk assessment 

9. Recommend a solution based on Analysis of Alternatives (AO A) 

10. Define areas of consideration for follow-on study 


The red line between “Verify Components” and “Verification of Subsystems” was 
chosen to illustrate where the project analysis left off. The proposed options identified 
component-level integration changes to the existing systems and platforms, which were 
evaluated using warfare analysis methods in support of SE to project potential 
effectiveness. 

The “V” model provided a simple method for requirements analysis and architecting 
at the SOS level, where much of the trade space within systems was highly constrained 
by existing, proven designs that had been produced and deployed for operational use, 
post Milestone C in the acquisition life cycle fl7] . Asa practical matter, the SE trade 
space was constrained to bound cost and minimize impact to operational employment and 
availability of the contributing MH-60 and Fire Scout systems. The following constraints 
were placed on the trade space: 


• The Fire Scout and MH-60 were “given” as existing platforms, treated as Off-The- 
Shelf (OTS), since they are currently operational and fielded. 

• The proposed SOS configurations should be planned to be in place in fiscal year 2012 
to deploy on the LCS. A Capabilities Matrix specifying functionality and 
configuration for each platform is provided later in the report. 
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• The lifespan of systems under consideration is 10 years (2012-2022). This is the 
anticipated lifespan for the Fire Scout prior to the first major overhaul or block 
upgrade. 

Under these constraints, the Spiral-to-Circle model was chosen to augment the “V” 
model because it specifically addresses an SE process flow from the viewpoint of 
increments of system capability. Figure 5 presents the Spiral-to-Circle model [l 5 l This 
incremental model is key for framing how solutions based on component-level changes 
result in a level of system capability at a specific level of process maturity. 



Figure 5: Spiral to Circle Process Model 


The SE activities are arranged within the spiral to show the progression of detail 
and confidence in the system definition. For example, a system specification is the result 
of requirements definition and analysis activities. To achieve an actual system design, 
the subsequent activities of prototyping, reviews, function allocation and trade studies, 
between the need statement and the solution design remain to be accomplished. The 
alternatives proposed by this project were the result of the SE activities up to detailed 
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design suitable for defining a materiel solution across the SOS. The red line on the 
model shows the "stopping point" for this project. 

The proposed alternatives were the result of the early SE activities that support 
definition of an increment of ASUW capability allocated across the SOS platforms and 
systems. No systems have actually been built or modified beyond their current 
configuration as part of this project, and thus Verification of Subsystems and Beyond has 
been left for potential future work. 

A brief description of the path through the SE process is provided below, as segue 
to a more detailed treatment later in the report. Figure 6 shows the functional 
decomposition of the ASUW mission as it relates to the Fire Scout and MH-60 aboard the 
LCS ship. This diagram is used to plot the project course along the SE “V” model 
starting with Requirements Definition. From the functional decomposition of the ASUW 
mission, the project developed a set of requirements, shown in the gray horizontal bars, 
for each of the mission functional areas. 

The definition of these mission functional requirements led to the need to define a 
real-world Tactical Situation (TACSIT) and mission scenarios. The result was a scenario 
for SWARM defense through a geographical choke point, representative of stressing 
operational conditions. Definition of the scenario supported allocation of requirements to 
particular mission systems and revealed the need to develop a CONOPS to evaluate 
interoperability opportunities. The successful development of the mission scenario and 
CONOPS required definition of the threat, the operational environment, and the 
operational requirements for the LCS ship in this environment. At this stage, the 
capabilities of each of the stand-alone AVs was examined to identify interoperability 
opportunities within the limitations and restrictions established for the project. 

Constraints were also identified, such as “establishing baseline AV functionality 
as of FY2012” and “no incorporation of additional functionality such as weapons or 
additional sensor systems.” These limitations were derived from interface with the 
stakeholders, understanding that the first tactical deployments of the Fire Scout and MH- 
60 were scheduled for FY12, and that incorporating additional functionality as described 
above would pose high risk to that deployment schedule. 
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Figure 6: Functional Decomposition of Anti Surface Warfare Mission 
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Exploring the opportunities and constraints led to evaluating opportunities for 
interoperability to support the mission scenario and CONOPS, ultimately leading to 
evaluation of the data sharing functionality. In order for the Fire Scout and MH-60 to 
operate effectively in the ASUW mission, they must be able to identify the targets in the 
area of interest and classify those targets as friendly, neutral or hostile. Identification and 
classification requires communication to decision makers on the LCS ship, so the project 
focused on effective communication with decision makers. Next, KPPs and MOEs were 
developed to quantify “effectively communicate” and the AVs were analyzed from the 
OV-1 interface perspective to define the communications “channels” or “li nk s” required 
to support the ASUW mission through the decision-making chain. By defining these 
links the project arrived at the bottom of the “V” model. At this point in the SE process, 
the project developed a warfare analysis model using the Naval Simulation System (NSS) 
to simulate the effects of the alternative SOS configuration in order to characterize 
impacts to decision-making performance. The modeling activity established and then 
evaluated the impact of changes to the system connectivity or links from a performance 
or data / information distribution perspective. The analysis of the output of the model led 
to a set of alternative approaches which were evaluated for performance, cost, and risk. 

In terms of the SE process, this activity represents activities working back up the right- 
hand side of the “V.” 

An architecture was developed to aid definition and allocation of interfaces and 
functionality based on the CONOPS, and to confirm definition of KPPs and MOEs to 
allow objective evaluation of interoperability performance. The architecture was an 
important tool aiding M&A plans and use of the NSS model. Details about the CORE 
architecture are provided in APPENDIX A - FUNCTIONAL DECOMPOSITION. The 
KPPs and MOEs were vetted with the stakeholders to ensure that they were meaningful 
and measureable. The key project metric was identified as the Time required To Identify 
(TTI) a target as a threat. 

The SOS architecture comprised of MH-60, Fire Scout and LCS was refined for 
modeling using requirements derived from the KPPs and MOEs. Analysis of the 
architecture associated with TTI revealed three distinct opportunities to enhance 
interoperability through improvement of communication paths or “channels.” One 
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channel enhancement was exclusively a function of the shipboard system integration 
only, one was between the ship and the MH-60, and the third was between the MH-60 
and Fire Scout. Because enhancements to any one of these communication channels had 
potential to improve interoperability, each one was approached as an independent effort 
or alternative. Further, it was recognized that the three enhancements could be 
implemented in combination or altogether to improve effectiveness and achieve a 
different mix of interoperability versus cost, risk and schedule constraints. This situation 
led to the adoption of the secondary SE approach shown in the Spiral-to-Circle figure. 
Moreover, this situation became the basis for modeling the baseline and project 
alternatives in NSS. 


II. PROBLEM DEFINITION 

A. INITIAL PROBLEM STATEMENT 

Given the CNO objective to achieve a predominantly unmanned force structure 
by 2030, and the pressing need to counter emerging threats, there was strong potential 
for an SOS solution comprised of integrated legacy systems augmented by advanced 
technology and concepts to afford new alternatives within the constraints of operational 
tempo and fiscal reality. The Fire Scout and the MH-60 helicopter have already 
demonstrated high potential for delivering enhanced capability when operating 
synergistically. The Navy has expressed interest during the stakeholder interview in being 
able to monitor data gathered by the Fire Scout. Interest was also expressed in the ability 
to potentially take over control of the Fire Scout using an on-aircraft control station to 
support emergent mission requirements.. 

This research focused on defining alternatives for enhanced mission effectiveness 
through increased interoperability and integration for the Fire Scout and MH-60. The 
initial problem statement, modified later in this chapter, was framed by this question: 

Does an integrated SOS of MH-60, Fire Scout and LCS working on a shared 
COTP with enhanced data communication achieve a more effective solution against 
SWARM threats? 
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Specifically, the project explored the available trade space for the MH-60 to 
support mission-based AV and mission systems control and data/payload exploitation. 

For example, when equipped with enhanced data link capability, the MH-60 could 
provide bi-static target isolation and laser targeting for the Fire Scout. Sensor fusion 
would also be available by combining data collected by the Fire Scout with that collected 
by the MH-60, transmitting all back to the ship for analysis and decision-making. The 
potential to share data between platforms and achieve a distributed “kill chain” supported 
increased capability to address threats and targets in contested environments with greater 
accuracy and decreased timelines. 

The project requirements were developed through iteration with stakeholders, 
including Program Office representatives and Operational Requirements Sponsors. 

These requirements have been documented such that they could eventually be refined and 
submitted using the JCIDS process as a program Capabilities Description Document 
(CDD), and approved for program initiation. 

B. NEEDS ANALYSIS 

The “LCS Aviation Mix Operations Assessment’’^ 18 ^ was commissioned by 
OPNAV N88 requirements officers and the Program Manager from the Navy’s UAV 
office (PMA-263) to established the foundational analysis for the “optimal mix” of 
manned and unmanned aircraft to perform ASUW at an enhanced operational level. This 
assessment studied the effectiveness of MH-60 and Fire Scout aboard both versions of 
the Navy’s LCS for employment in long and short duration operational scenarios. 
Excursions of the study supplemented a notional baseline aviation mix of one MH-60R or 
MH-60S helicopter and one Fire Scout with multiple Fire Scouts or Small Tactical 
UAVs. Several TACSITs and mission areas, including ASUW, ASW and MIW were 
explored for impacts to mission effectiveness, suitability, and affordability. In each 
operational employment assessment the study evaluated the number of contacts detected, 
number of flight hours flown, number of threat kills, and amount of area searched or 
monitored as the primary MOEs for varying aviation asset mixes. The summary 
conclusions of the study were that UAV and MH-60 aviation mixes benefited ASUW 
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scenarios more than ASW and MIW scenarios. Further, the study concluded that the Fire 
Scout was the UAS platform of choice for the mix with the MH-60. Specific results in 
the ASUW scenario showed the addition of the Fire Scout or multiple Fire Scouts led to 
more hours flown, more area searched, more contacts detected, and more threat kills 
occurring — all these benefits performed with less manpower and reduced fuel costs as 
compared with manned assets. The summary results of the study is presented in Figure 7, 
which shows key MOEs relevant to the project. 
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Figure 7: MH-60 and UAV Aviation Mix Study - ASUW Effectiveness 

Since the conclusion of this study in 2007, there has not been any further analysis 
or proposed method of implementation beyond presenting the results of the aviation mix 
as shown. The research conducted for this project recognized the fundamental value of 
the “optimal mix” analysis and extended this work from warfare analysis into the early 
phases of the SE process. The goal was to provide a “pathfinder” to potentially feasible 
solutions that could be implemented by the contributing programs. There are feasible 
approaches to fulfilling the needs described above at an affordable cost and within an 
acceptable level of risk. This first needs analysis supports the requirement for integrating 
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the Fire Scout and MH-60 on an LCS by resolving the question of "How to do it?" which 
was presented after evaluating a collaborative CONOPS and defining any additional 
effectiveness improvements beneficial to the warfare area. 

These three platfonns together (Fire Scout, MH-60 and LCS) with current 
programmed communication capabilities can be expected to provide commanders with 
near-real time imagery and data required to support ISR requirements to detect and 
engage swarming boats, ensure landing areas are free of amphibious craft, provide 
overhead communications relays, and conduct intelligence gathering and targeting. 

1. Stakeholder Input 

Stakeholder input was important for ensuring the true requirements were 
understood during investigation. Gathering stakeholder input involved not only taking 
initial written or verbal direction regarding what was required, but also involving the 
stakeholders continually during the project for additional information, as well as “heading 
checks” to make sure the project was meeting expectations as necessary. This project 
continually used the stakeholders to bound the problem and focus on the solution set. 

a) Stakeholder Background 

The stakeholders for this project encompassed fleet operators, requirements 
officers, and acquisition managers. The fleet operators were represented by Air Test and 
Evaluation Squadron One and their interests were in representing the scenario correctly, 
ensuring the assumptions incorporated into the NSS model were acceptable and as 
realistic as possible, and additionally, that any results were meaningful and reasonable for 
implementation. Several project officers from the squadron including the UAV and MH- 
60R project officers were the primary stakeholders for the period of the study. The 
requirements officer stakeholder group represented requirements officers from OPNAV 
N88 Air Warfare and the N2N6 Intelligence and Networks Divisions. CAPT David 
Fisher, Head Maritime Requirements N88 represented the navy’s primary vertical lift 
platform, the MH-60, and CAPT Mike Carsley, Head Short Range UAS requirements, 
represented the Navy’s interests for the MQ-8 Fire Scout. These two stakeholders 
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manage fleet requirements and recommend the direction of the Navy’s future for these 
two platfonns. During this study these stakeholders’ primary interests were in defining a 
CONOPS for the MH-60 and Fire Scout aboard the LCS and identifying what 
contributions these two air platforms bring to guarding against a hostile SWARM attack. 
During the project the stakeholders defined a relevant real-world area and numerous 
starting criteria/conditions for scenario development. 

The acquisition stakeholders for this project were CAPT Dean Peters, Program 
Manager (PMA-299) for Multi-Mission Helicopters (MMH), and CAPT Tim Dunigan, 
Program Manager (PMA-266) for Short Range Vertical UAS at NAVAIR. As Program 
Managers, these stakeholders procure solutions for the previously mentioned 
requirements offices and are responsible for total life cycle management of the two 
platforms, including sustainment and continued war fighting relevance. CAPT Peters’ 
and CAPT Dunigan’s primary interest during the course of the project was ensuring the 
project accurately represented the capability of the platfonns and research defined the 
performance, technical and cost characteristics of solutions. Both PMAs planned 
concurrent live demonstration of capabilities similar to one of the project alternatives. It 
was expected that lessons learned from the project would be applied for the 
demonstration. 

b) Initial Scenarios 

The initial scenario for the project was determined by the project stakeholders at a 
meeting held on March 24, 2010. During this meeting the stakeholders requested the 
project determine a CONOPS for the upcoming deployment of the MH-60 and Fire Scout 
on LCS. There was currently no existing combined CONOPS and definition of one 
would benefit the Navy. Additionally, the stakeholders specified the mission scenario for 
the CONOPS that called for LCS deployment to an area where the risk of a SWARM 
attack was high. The objective was to research how employment of the air systems could 
improve situational awareness for all assets and commanders, improve threat 
identification, and ultimately, improve threat engagement. Starting conditions for this 
scenario were agreed upon by all and included: 
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Assets 


• One LCS operating independently, “sole ship steaming” 

• One MH-60 variant helicopter* 

• One Fire Scout * 

Time Period 

• The length of a mission transit of a risk area, “choke point” 

Operational Control of Units 

• Air assets under orders from the LCS 

• Weapons release approved by the ASUW Commander 

Sensors 

• Currently in the program of record for the assets 

• The Fire Scout RADAR, not currently part of the baseline configuration, 
had been selected with planned integration in fiscal year 2012, within the 
project timeline 

Weapons 

• Ship - Gun, Non Line of Sight (NLOS) 

• Air - Gun, Hellfire Missile, Low Cost Guided Imaging Rocket (LOGIR), 
Advanced Precision Kill Weapon System (APKWS) 

For the combination of airborne assets, marked with an asterisk in the above list, 
stakeholders requested that one asset mix employ a Fire Scout with RADAR and an MH- 
60S (which does not have RADAR), and one asset mix employ be a Fire Scout without 
RADAR and an MH-60R (equipped with a RADAR and Electronic Support Measures 
(ESM)). These alternative configurations ensured an airborne maritime RADAR was 
employed for the CONOP. 

Based on this stakeholder input, the project OV was refined to identify a physical 
SOS architecture for the proposed scenario. Figure 8 presents the current capabilities as a 
baseline case and Figure 9 presents the proposed capability upgrades to improve system 
effectiveness. The yellow lines in both figures call out the communication paths 
important to the project research. 
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2. Current Capabilities 


The following section describes the current capabilities of the MH-60R, MH-60S, 


Fire Scout, and LCS, based on extensive research of program, technical and literature 


sources. 


[19-23] 



Figure 8: Baseline - Current Capabilities 


46 








rn 


•RADAR 

•TRACKS 

•SAR/1SAR 

•TCDL 






•RADAR 

•SAR/1SAR 

•TCDL 

•FLIR 

•IFF 

•ESM 


Figure 9: Future Capabilities 

a) MQ-8B Fire Scout 

The Fire Scout VTUAV was developed by Northrop Grumman for both Army 
and Navy customers. The Navy variant is presented in Figure 10. The Navy program is 
managed by PMA-266. The Fire Scout is currently being introduced into the US Navy 
Fleet, to be deployed on any ship that an MFI-60 helicopter can deploy on including 
aircraft carriers, frigates, destroyers, and the LCS. 

The roles for the Fire Scout are still being determined, but with its present suite of 
mission equipment, it is performing an ISR mission to detect and monitor potential 
threats to the battle group. Currently, the Fire Scout has the ability to autonomously take¬ 
off from and land on any aviation-capable warship and also at unprepared landing zones 
close to the Forward Edge of the Battle Area (FEBA). It is equipped with the Tactical 
Common Data Link (TCDL) for both AV and payload Command and Control (C2). 
Mission equipment includes Electro-Optical (EO) and Forward Looking Infra-Red 
(FLIR) sensors. It can carry out surveillance, find tactical targets, track and designate 
targets and provide accurate targeting data to strike platforms such as strike aircraft, 
helicopters and ships. The Fire Scout is also able to carry out battle damage assessment. 
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Recent concerns about small fast boats used for piracy and for swarm attacks highlight 
the need for extended coverage and ISR capability. Initial system-specific CONOPs focus 
Fire Scout employment on self-protection and keeping the sea-lanes clear, enabling sea 
control and littoral superiority. 



Figure 10: MQ-8 Fire Scout (AUYSI 2005) 


b) MH-60R 

The MH-60R helicopter is manufactured by the Sikorsky Aircraft Corporation. Its 
common cockpit avionics, mission avionics, and survivability avionics are integrated by 
Lockheed Martin Systems Integration. The MH-60R MMH was designed for the Navy’s 
sea control mission and extends the search and attack capabilities of U.S. naval 
combatants, deploying helicopters directly from these ships with airborne mission 
systems integrated directly into the ship’s Combat Information Center (CIC) via data 
link. Along with deployment from air-capable combatants, the helicopter can operate 
from aviation ships and a variety of other naval ships. 

The MH-60R primary missions include Surface Warfare (SUW), Anti-Submarine 
Warfare (ASW), Command, Control, Communications (CCC), Command and Control 
Warfare (C2W), Mobility (MOB) and Non-Combat Operations (NCO). Eight secondary 
missions are also assigned to the aircraft. Traditional roles in Search and Rescue (SAR), 
Medical Evacuation (MEDEVAC), Vertical Replenishment (VERTREP), Naval Surface 
Fire Support (NSFS), and Communications Relay (COMREL) are encompassed within 
these mission areas. 
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Figure 11: MMH Equipped for ASUW 


When used in an SUW mission, as depicted in Figure 11, the aircraft provides a 
mobile, elevated platform for observing, identifying, and localizing surface platforms 
beyond the parent ship’s radar and/or ESM horizon. When a suspected threat is detected, 
classification and targeting data is provided to the parent ship via the data link for 
surface-to-surface weapon engagement. Air-to-Surface missile equipped aircraft may 
conduct independent or coordinated attack, depending upon the threat and tactical 
scenario. In the ASW mission, the aircraft deploys from the parent ship to localize, 
classify, track, and, if necessary, attack when a submarine has been detected by the ship’s 
towed-array sonar, hull-mounted sonar, or by other internal or external sources. 

In the SAR mission, the aircraft searches for and locates a target/object/ship or 
plane and rescues personnel using the rescue hoist. In the VERTREP mission, the 
aircraft transfers material between ships, or between ship and shore, via the cargo hook. 
In the MEDEVAC mission, the aircraft evacuates ambulatory and/or litter-bound 
patients. In the NSFS mission, the aircraft provides a platform for spotting and 
controlling naval gunfire for either the parent ship or other units. In the COMREL 
mission, the aircraft serves as a receiver and transmitter relay station for Over-the- 
Horizon (OTH) communications between units. 
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c) MH-60S 


Another member of the MMH product line, the MH-60S is also managed by 
PMA-299. The MH-60S relies on the same airframe as the MH-60R, but is configured 
differently to address the assigned missions. The MH-60S missions include Vertical 
Replenishment (VERTREP), Vertical Onboard Delivery (VOD), amphibious Search and 
Rescue (SAR), Airhead operations. Non-combatant Evacuation Operations (NEO), 
Medical Evacuation (MEDEVAC), Special Warfare Support, Combat Search and Rescue 
(CSAR), Maritime Interdiction Operations (MIO), Anti-surface Warfare (ASUW), CV 
Plane Guard/SAR, Air Ambulance, and Organic Airborne Mine Countenneasures 
(OAMCM). 

d) Littoral Combat Ship 

The LCS is a networked, agile, stealthy surface combatant capable of defeating 
anti-access and asymmetric threats in the littorals. (Anti-access refers to a hostile force 
boundary that prevents communication or physical entry into an area of interest. Anti¬ 
access may be achieved through blockade, mines, or barrage jamming, for example.) 

This relatively small, high-speed combatant can operate in environments where it is less 
desirable to employ larger, multi-mission ships. It has the capability to deploy 
independently to overseas littoral regions, remain on station for extended periods of time 
either with a battle group or through a forward-basing arrangement. It can operate with 
Carrier Strike Groups, Surface Action Groups, in groups of other similar ships, or 
independently for diplomatic and presence missions. 

The LCS relies heavily on manned and unmanned vehicles to execute assigned 
missions and operate as part of a netted, distributed force (e.g., Fire Scout, MH-60). 

The LCS is capable of operating at low speeds for littoral mission operations, transit at 
economical speeds, and high-speed sprints, which are necessary to avoid or prosecute a 
small boat swann or submarine threat, conduct intercept operations over the horizon, or 
for insertion or extraction missions. 

The LCS communicates with the Fire Scout through the Fire Scout Control 
Station (FSCS). It sends control signals (for both the AV and the sensor package) over a 
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bi-directional UHF link, receiving command acknowledgment from the Fire Scout across 
that same link. The Fire Scout sends sensor data back to the LCS ship over a Tactical 
Common Data Link (TCDL) channel. The TCDL link is maintained using directional 
antennas on both the Fire Scout and the LCS. The LCS has two antennas, one forward 
and one aft, to maintain communication through blockages associated with the ship's 
structure. There are two configurations of LCS ship, one of which has two separate 
TCDL channels available, and the other, which has only one TCDL channel available. 
This was a significant consideration when analyzing alternatives. 

LCS communications with the MH-60 consists of VHF and UHF voice and data 
communications in various modes via ARC-210 radio, as well as Link-16 for aircraft 
data, and Hawk Link for sensor data. These data li nk s are not common with TCDL in 
either transmit or receive modes. A diagram of the LCS’s major subsystems is shown 
below in Figure 12. 
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Figure 12: LCS Components and Subsystems 


3. Needs 

The stakeholders identified the most pressing need as a mission scenario: 
Defending the LCS against multiple small boat threats. Once the HVA is secure, the 
operational scenario could be to pursue further engagement of threats in order to destroy 
all hostile units. This ultimate objective defined the mission scenario and became the 
focus of the project research. This top-level requirement was decomposed into 
requirements allocated to scenario phases for further study and analysis. 

Analysis of this mission scenario determined that it was composed of three phases 
to accomplish mission success. The first phase was the Planning Phase. This phase 
involved all the activities that shipboard mission planners and aircrews perform before 
launching or transiting the hostile risk area, in this case, the choke point. Typical 
activities consist of familiarization with area intelligence for the latest probable locations 
of hostile units and their recent tactics. Another important activity was the configuration 
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of system mission packages including fuel load and weapons, for example, and selection 
of weapons, such as rockets or guided missiles based on the size of the expected threat. 
During this phase, the projected search areas and expected divisions of search area 
responsibilities between platfonns were defined. 

The second phase of the scenario was the “Build the Surface Picture” phase. The 
objective of this phase was developing situational awareness for all assets involved in 
order to place the LCS in an appropriate state of war fighting or protective readiness, as 
well as to place its commanders in the proper state for required operational decision 
making. Typical activities in the phase include ship and air assets employed to search, 
detect, and track all contacts nearest to the ship, initially, and then contacts in the areas of 
interest along the ship’s Projected Intended Movement (PIM). Derived requirements to 
perform this phase included: (1) ship and air asset perfonnance to reach areas of interest, 
which equates to speed, endurance, movement; (2) sensors capable of detecting contacts, 
which equates to sensitivity, resolution, range; and finally, (3) a communications system 
and network that can move orders/direction and contact infonnation to the appropriate 
assets or commanders, which for interoperability, equates to the ability to transmit data, 
voice and images. 

The third phase entailed resolving contacts found in the previous phase of the 
mission in order to classify and identify each contact to a sufficient degree for making a 
hostile or friendly determination. Derived requirements for these top-level requirements 
encompassed sufficient sensor capability to provide the necessary data characteristics for 
commanders to make those determinations with confidence. These necessary 
characteristics included, at a minimum, contact behavior and detailed contact visual 
descriptions, such as seeing human images and contact cargo or weapons. 

The final phases of the mission entailed engaging hostile contacts, assessing the 
situation at the conclusion of an engagement, and then conducting after action reports and 
reviews of the mission. Derived requirements for this portion of the mission scenario 
included: provide sufficient communications and targeting information to employ a 
weapon; provide sufficient sensor capability to assess damage to contacts; and provide 
sufficient platform capability to re-engage contacts. Research on these final phases, and 
specifically into the benefit of interoperability on target engagement, was beyond the 
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time period allotted for the project. The project research was conducted with the 
complete set of needs and activities in mind and artifacts were developed for future use 
by sponsors, stakeholders, or research students. 


4. Constraints 

Along with addressing the needs of the scenario, the project team recognized the 
scenario constraints. The constraints of the scenario were almost a mirror-image of the 
needs. Although the derived requirements identified above listed the needed capabilities, 
the actual performance of the contributing platforms and systems became the constraints 
identified and assessed in this project. To specify these constraints and identify limits to 
performance or integration due to the original design or operational use, the project team 
performed a thorough study of the capabilities of the platforms. Tables 1 and 2, 
presented below, are sample artifacts from this activity. 


Table 1: MH-60R Current Capabilities Matrix for Identification of Constraints 


Mission 

Threat/ 

Objective 

Sensor Systems 

Communication Systems 

Weapons 

Recording 

Systems 



FUR 

RADAR 

AIS 

V/UHF 

RADIO 

ARC-210 

SATCOM 

Data Link 

"Hawklink" 

Link-16 

Blue 

Force 

Tracker 

Hellfire 

M240 

GAU-17 

Torpedo 

DVR 

VCR 

ISR 

Standard 

X 

X 


X 

X 

X 

X 


X 

X 


X 

X 


Extended 

Range 

X 

X 


X 

X 

X 

X 






X 


Threat 

Interdiction 

Small, Fast 

X 

X 


X 

X 

X 

X 


X 

X 


X 

X 


Swarm 

X 

X 


X 

X 

X 

X 


X 

X 


X 

X 


Military Ship 

X 

X 


X 

X 

X 

X 






X 


Board & Search 

X 

X 


X 

X 

X 

X 






X 



















Table 2: MH-60S Current Capabilities Matrix for Identification of Constraints 
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The tables show the mission systems configurations of sensors, communications 
and weapons by mission type for the MH-60R and MH-60S helicopters, respectively. 
The tables highlight the major differences between the two MMH variants, most 
importantly the fact that the MH-60R is equipped with RADAR and data links for the 
same missions, where the MH-60S is not. 

Using these artifacts, the project further identified the physical and performance 
limitations and used this information as input to the modeling activities. Table 3, for 
example, was compiled to identify the capabilities of the air platforms’ communication 
systems that would set the baseline for modeling and constrain definition of 
interoperability alternatives. 

Table 3: Platform Communication Capability Constraints 






VOICE .ARC-210 

•Internal 

•ARC-210 

•Internal 

Comms director 

comms 

director 

comms 

relay 

from CS 

relay 

from CS 

Track Data »TCDL to 

•TCDL to 

• Link 16 to 

•TCDL to 

CIC 

• Link 16 to 
CIC 

CS 

CIC 

CS 

Video Data »TCDL to 

•TCDL to 

• None 

•TCDL to 

CIC 

CS 


CS 

Video .None 

Data/ 

Control to 
shooter 

•None 

• None 

• None 


Once the needs and constraints research was completed, the project team 
concluded that sufficient platform performance was available to conduct the desired 
mission scenario, sensors supported the phase requirements, and further, that weapons 
existed to accomplish the engagement, if required. At the same time, the project team 
identified constraints in the communications capabilities of the total weapons systems for 
the defined scenario that were deemed to have significant opportunity for improvement. 
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a) Initial Requirements 


After assessing the need and constraints, the project defined the initial requirements for 
development of the research models in the context of the mission scenario. An example of the 
stakeholder mission scenario is presented in Figure 13. The scenario portrays the LCS transit 
through a geographical choke-point where the HVA may be most vulnerable to a SWARM, with 
little room for recourse and maneuver. 



Figure 13: LCS/MH-60R/Fire Scout CONOPS for ASUW Protection from Small Boat 

Swarm through a Choke Point 

This real-world scenario requires a HVA to transit a choke point with heavy transit by 
commercial shipping vessels. Threat analysis indicated that the HVA, in this case LCS, 
would be vulnerable to a small boat swarm attack, where several small vessels 
intermingle with commercial shipping and then attack using either random or coordinated 
maneuvers. In this scenario, the critical measure was determined to be the time required 
to identify targets and classify them as threats, or TTI. The presence of commercial 
shipping created a target-rich environment, and the time required for a single aircraft, 
either Fire Scout or MH-60, to identify all of the targets and classify them as threats via 
coordination with an appropriate Decision Maker could be excessive. Sending out 
multiple assets, both a Fire Scout and an MH-60, in an uncoordinated manner could 
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provide some reduction in the time to identify and classify. Providing a means to 
coordinate between the Fire Scout and MH-60 was proposed to provide even more 
improvement in the time to identify and classify, and that is the focus of the remainder of 
this report, to analyze and quantify potential benefit associated with the KPPs and MOEs 
defined to support a relevant CONOPS (to be described more fully later in this report). 

In this context, the list of high-level initial requirements is provided below: 


Defend Against Small Boat Attack: 

■ Build Surface Picture 

■ Resolve Contacts of Interest 

■ Engage Hostiles 

■ Assess Mission (Post Engagement) 

■ Share Command and Control Data 


b) Assets in Play 

Identification of existing platforms and sensor and communications capabilities 
was performed by use of sources such as the Naval Aviation Training and Operating 
Procedures Standardization (NATOPS) manuals and platfonn program office 
consultation. The CORE SE tool was used to develop a high level architecture model and 
manipulate functionality for analysis of potential alternatives and to understand existing 
system capability, as well as capability gaps. This effort was rolled up into the 
development of an initial plan for further functional analysis. Figure 14, below, maps the 
current sensor configuration and relevant capabilities for the airborne platforms. 

[i 8][ 1 9][20][2 1 ] -phe ] <C y sensor from each platform that most benefits success for each 
scenario phase is highlighted. The key sensor from each platform that most benefits 
success for each scenario phase is highlighted. For Phase 1, “Create Surface Picture," 
the RADAR plays the key role for detection and tracking. For Phase II, “Resolve 
Contacts,” the FLIR and EO/IR sensors play the key role, contributing imagery for 
analysis of contact behavior and visual identification. For Phase III, “Engage Contacts,” 
the laser designator and Hellfire weapons are critical capabilities. 
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Surface 

Picture 


I 


Search Detect Track 




PHASE II PHASE III 


MH-60R 

•Radar 

•Track data 
•Visual/NVG 

•FUR 

•SAR/ISAR? 

•Visual/NVG 

•Laser 

•Hellfire 

•Crew served weapons 

MQ-8B 
(no radar) 

•Track data 
•AIS 

•EO/IR 

•Laser 





MH-60S 

•Track data 
•Visual/NVG 

• FUR 

•Visual/NVG 

•Laser 

•Hellfire 

•Crew served weapons 

MQ-8B 

(radar) 

•Radar 

•Track data 
•AIS 

• EO/IR 

•SAR/ISAR? 

•Laser 


* Key Sensors in Bold 


Figure 14: Current Sensor/Capabilities by Platform and Applied to Initial Phasing Plan 

C. REVISED PROBLEM STATEMENT 

Given the substantial guidance from Stakeholders, results from Needs and 
Constraints identification and the results of mission-based requirements analysis, the 
Initial Problem Statement was revised to focus the scope of effort and support 
development of a CONOPS and systems architecture associated with the deployment of 
the Fire Scout and MH-60 as part of an integrated SOS, while providing a framework for 
more complete assessment of enhanced performance based on interoperability. The 
initial problem statement was refined to address the specified threat and mission scenario: 

Does an integrated SOS of MH-60, Fire Scout and LCS, working on a shared 
COTP with enhanced data communications achieve a more effective solution defending 
LCS against SWARM threats? 
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SYSTEM CONFIGURATION AND OPERATION 


The following sections describe the process, approach and results for refining the 
SOS comprised of Fire Scout, MH-60 and LCS in response to the revised problem 
statement. The SE analysis focused on system configuration and mission operations, 
making the translation of operational requirements and functional architecture to physical 
allocation and activities. 

A. CONCEPT OF OPERATIONS AND MISSION SCENARIO PHASES 

Based upon the stakeholder-given scenario and capabilities-based assumptions, 
CONOPS were developed to capture and analyze interoperability effectiveness, focusing 
on the combined effects of the MQ-8B Fire Scout and MH-60 Seahawk. Because the 
mission commander, the key decision maker, is onboard the LCS, and much of the 
communication and coordination is accomplished through the host ship equipment, 
components of LCS are considered part of the system alternatives. 

The ASUW swann attack scenario was centered on the protection of the LCS as it 
transits through the choke point, depicted as “worst case” straights geography. To 
accomplish this mission, the project addressed the SOS control of the battle space beyond 
the sensor and weapons range of the LCS with the objective of neutralizing threats before 
they reach weapons engagement range of the HVA. Through functional decomposition, 
the defense from small boat attack operation was broken down into activities and grouped 
into three distinct primary phases, as discussed in the previous chapter. Phase I was 
defined as the development of the tactical surface picture, which includes the generic 
tasks of search, detect and track. Phase II was defined as the resolution of contacts, which 
includes classification of vessel type as well as identification as hostile, neutral or 
friendly designation for surface contacts. Phase III was defined as threat engagement, 
which includes threat vessel targeting and neutralization or attack and destruction. A 
complete analysis would also include a mission assessment phase for battle damage 
assessment (BDA) as well as pre-mission planning and post mission analysis. These final 
phases were beyond the scope of the project, but influenced the SE and modeling and 
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analysis activities in support of future, follow-on work. For the purpose of this report, the 
project focus was system effectiveness during the first three primary operational phases. 

As depicted in Figure 15, the three mission scenario phases of coordinated SOS 
operations run concurrently in execution. The ASUW mission commander depends upon 
airborne RADAR coverage to provide a continuous surface tactical picture (Phase I) 
throughout the entire transit. The importance of this phase in providing situational 
awareness is highlighted by the stakeholder guidance to examine scenarios where at least 
one air asset is configured with surface search RADAR. The MH-60R RADAR has 360- 
degree coverage and longer range than the RADAR to be incorporated into the Fire 
Scout, but both have the capability for automatic detection and tracking. This automated 
capability enables parallel processing of Phase I activities. While the surface picture is 
maintained by either the MH-60R or the Fire Scout (when fully integrated across the 
SOS), both can be employed to conduct the Phase II functions of classification and 
identification of contacts using EO/IR as the primary sensor source for imagery. These 
activities are more operator-intensive and require serial processing and significant 
coordination with the mission commander. The Phase III engagement functions are 
triggered by the results of Phase II in conjunction with satisfaction of Rules of 
Engagement (ROE). 
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Given the mission-scenario proscribed by the stakeholders, the project team 
determined that there were, in fact, two versions of the same situation from an analytic 
viewpoint. The airborne assets operating as coordinated SOS drove the need to establish 
two scenarios in response to the Stakeholder requirements. The combination of platform 
and sensor “footprint” or area of interest covered by the optimum platfonn-sensor 
coverage determined the two distinct variations, hereafter referred to as Scenario 1 and 
Scenario 2. These two scenarios share the same Stakeholder defined geo-political basis, 
but vary in terms of platform-sensor capability projected as geometric coverage (i.e., 
platform and sensor ranges). Scenario 1 was defined by the combination of an MH-60R 
equipped with RADAR and a Fire Scout without RADAR. Scenario 2 was defined by an 
MH-60S without a RADAR and a Fire Scout equipped with a RADAR. The key 
constraint was the Stakeholder demand for employment of an airborne RADAR as the 
key sensor for search and detection as critical to Phase I. Because the SOS 
configurations differ in terms of coverage and perfonnance, separate analytic scenarios 
were defined. Each of these SOS configuration-specific scenarios is described below, 
including the activities important to each phase. The CONOPS description is the basis 
for understanding how system configuration, functionality and performance pertains 
directly to mission activities and outcomes, setting the basis for measuring and assessing 
alternatives in later Modeling and Simulation (M&S) activities. 

1. Scenario 1 

The specific CONOPS for Scenario 1 is represented in Figure 16, below. In this 
scenario an MH-60R is teamed with a Fire Scout that is not equipped with RADAR to 
protect the host LCS platform during transit through the straights. This notional 
operation begins 100 nautical miles prior to entry into the straights and lasts 12.5 hours 
with the LCS traveling an average of 20 knots. The take-off, landing and re-launch timing 
for both aircraft is designed to maximize overhead coverage while de-conflicting time on 
deck and keeping both assets airborne through the constrained 50 mile traffic pattern 
where the LCS is most vulnerable. The MH-60R, with a maximum endurance of 3.5 
hours, cannot provide coverage for the entire operation without more than 3 sorties so the 
initial take-off is held until the LCS is 70 nm from the entrance of the straights or until 
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indications of threat dictate that earlier launch is required. Whenever only one asset is 
airborne, TCDL is used for communications and data exchange with LCS since it is 
capable of transmitting streaming video from the EO/IR sensors. When both assets are 
airborne, the MH-60R conducts operations using UHF voice and Link 16 for data. 



Figure 16: Scenario 1 CONOPS 

a) Scenario 1 - Phase I 

In the Sceanriol CONOPS, the primary asset assigned to accomplish the Phase I 
activities of building and maintaining the surface picture is the MH-60R Seahawk, 
equipped with a surface search RADAR. The majority of the operation is conducted at an 
optimal altitude for RADAR coverage so that a continuous surface tactical picture can be 
maintained. Automatic track generation, long range and 360-degree RADAR coverage 
capabilities result in highly efficient Phase I activities. The Fire Scout augments the 
surface search with AIS tracks only, since it has no RADAR in this scenario. The Fire 
Scout also performs limited search functionality with the EO/IR payload during periods 
when the MH-60R is not airborne. In this scenario, the COTP is maintained on the LCS 
by the ASUW commander with inputs from both aviation platforms. 
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b) Scenario 1 - Phase II 


An essential element of the CONOPS is that Phase II operations are conducted 
concurrently with Phase I. The tracks generated by the MH-60R are shared with the LCS 
CIC and used to cue the EO/IR sensors for both assets. The track information must be 
passed verbally to the Fire Scout operators at the tactical control station because there is 
no direct data path from CIC. The ASUW commander aboard LCS directs the airborne 
asset tasking priorities and assigns sectors for split coverage to maximize the efficiency 
of contact investigation. Each air asset then begins methodical classification and 
identification of all vessels within their assigned sectors starting in close and moving 
outward from the HVA. The MH-60R uses SAR, visual and night vision goggles (NVG) 
during night operations to supplement the primary EO/IR sensor in classification and 
identification functions. Track information is transmitted verbally or via Link-16. The 
Fire Scout relies exclusively on the Britestar II EO/IR sensor, but is able to transmit 
streaming video to the tactical control station via TCDL. Fire Scout video is not available 
on the LCS network so the ASUW commander must visit the control station to observe 
the video. Except for critical contacts, most information will be passed via verbal 
communications. To effectively prosecute the operation, the ASUW commander must 
ensure the classification and identification infonnation for all vessels is correlated with 
the tracks maintained in the COTP. He is also responsible for ensuring that ROE criteria 
are met prior to contact designation as hostile. These criteria are not addressed here but 
include both vessel characteristics and observed activities. 

c) Scenario 1 - Phase III 

There are many potential CONOPS for the conduct of Phase III activities. Actual 
execution of targeting and engagement is situation and weapon dependent, and specific 
tactics are beyond the scope of this study. Since the focus of this research is 
interoperability, the CONOPS associated with a coordinated attack are briefly addressed. 

Only the MH-60R is equipped with weapons and therefore, in all cases, fills the 
role of the shooter. Once a hostile contact is identified, the preferred method of 
engagement is a coordinated attack due to the added safety advantage of sensor-to- 
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shooter standoff range from the target, but requires both assets to be on scene. To execute 
this task the Fire Scout maintains a safe stand-off distance, holds continuous EO/IR track 
and illuminates the target. Concurrently, the MH-60R readies the weapon (i.e, the 
Hclllirc missile), ingresses covertly to the target, fires the weapon when in range and 
egresses the area immediately. Since data cannot be directly transmitted between 
vehicles, verbal coordination is required to assure the right contact is targeted and to 
confirm the laser designator is on target. The MH-60R may take immediate action to 
conduct an attack if Fire Scout is not in the area, but will be more vulnerable. 

2, Scenario 2 

The CONOPS for Scenario 2 features the same threat and features the MH-60S 
and Fire Scout equipped with RADAR, depicted in Figure 17. The operational flow and 
LCS transit is identical while the take-off, landing and re-launch timing for the aircraft is 
shifted to account for and take advantage of different capabilities. The MH-60S has 
longer endurance so it can remain on station longer, therefore it may launch first. With 
the addition of surface search RADAR capability on the Fire Scout, its endurance is 
slightly decreased due to payload weight, but it can still remain on station for the entire 
evolution with three sorties. Again, the plan keeps both assets airborne while the LCS is 
in the straight transit traffic scheme. In this scenario, only the Fire Scout is capable of 
transmitting video from the EO/IR sensor via TCDL communications and data exchange 
with LCS, because the MH-60S is not equipped with data links. 
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Figure 17: Scenario 2 CONOPS 

a) Scenario 2 - Phase I 

In the CONOPS developed for this scenario, the primary asset assigned to 
accomplish the Phase I activities of building and maintaining the surface picture is the 
Fire Scout. It remains at best RADAR coverage altitude for the majority of the operation, 
but must continually change direction to maintain the surface tactical picture since its 
RADAR does not provide 360-degree coverage. It has shorter range than the MH-60R 
but does have automatic track generation capability. The contacts generated must be 
verbally passed to CIC so that the ASUW commander can maintain the COTP. The MH- 
60S augments the surface search visually or via NVGs at night. It also performs limited 
search functionality with the EO/IR payload during periods when the Fire Scout is not 
airborne. 
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b) Scenario 2 - Phase II 


As in Scenario 1 the CONOPS includes Phase II operations concurrent with Phase 
I. Since the Fire Scout must maintain the surface picture by changing RADAR aspect 
angles, its efficiency will be decreased in classifying and identifying contacts. In this 
scenario the tracks generated by the Fire Scout are shared from CIC to the MH-60S for 
cueing of its EO/IR sensor. All other Phase II CONOPS are identical to those in 
Scenario 1. 

c) Scenario 2 - Phase III 

The CONOPS for Phase III activities are identical to Scenario 1. Again, the Fire 
Scout is unarmed so it fills the roll of target designator for the MH-60S in the execution 
of coordinated attacks. 

3. Communications Analysis 

Through systems analysis and CONOPS development, it was detennined that 
system interoperability has critical limitations in communications. Timing delays in the 
information flow required to execute each operational phase have a significant impact on 
the MOEs chosen for evaluation of mission effectiveness. In order to understand these 
limitations, a deeper investigation was conducted to understand the timing logic 
associated with the specific tasks involved in each phase. SE Functional Flow Block 
Diagrams (FFBD) were used to depict and analyze the communications timing logic for 
impacts to performance and effectiveness. 

a) Phase I 

Figure 18 represents the functional flow of tasks involved in Phase I. The FFBDs 
were developed to clarify the sequence of activities and associated system employment. 
(This type of information informs later specification of system modification, especially 
software functionality.) This diagram is applicable to whichever asset has RADAR 
capability and is assigned with generation of contacts and building the surface picture. It 
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includes the tasks required to ensure that the Tactical Action Officer (TAO), acting as the 
ASUW commander, has complete situational awareness and can maintain control of the 
operation. Although the tasks are linked in a serial fashion multiple contacts can be 
processed simultaneously. 


Launch 


Next 



Output to 
Phase II 


from TAO 


Figure 18: Phase I Functional Flow 

After launch and climb to RADAR altitude, the RADAR-equipped helicopter 
transits to station and begins its search. Detection and tracking are dependent upon both 
the RADAR senor capability and the physical distance from contact. The physical 
limitation is overcome by the movement of the air platform, transit, and may introduce 
time delay in accomplishing those tasks. The transit delay is calculated from the range to 
the contact, sensor detection and tracking range and transit speed. There is no associated 
time delay for contacts already located within the sensor field of view. It should be noted 
that when the Fire Scout is providing the RADAR picture the transit task must also 
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account for direction since the RADAR does not have 360-degree coverage. A ladder 
type search pattern (or some search pattern that optimizes coverage) was assumed to be 
flown to update contacts in all directions. 

Since the RADAR sweep functionality is automated, there is no time delay for the 
Search task after RADAR initialization. Similarly there is no time delay for subsequent 
detections after the first contact is generated because all contacts in the field of view are 
simultaneously developed by the processor when RADAR energy is received. Time 
required to generate track solutions depends on RADAR mode but use of the automatic 
track generation functionality makes the track task almost instantaneous. The loop back 
to the transit and search task illustrated on the functional flow diagram represents the 
continuous process of track generation that is not interrupted as the data is 
communicated. 

After a track is generated it must be passed to the TAO in CIC to be added to the 
COTP. The MH-60R transmits multiple contacts simultaneously via Link 16, or TCDL 
when not in use by the Fire Scout. The Fire Scout contacts are transmitted to the fire 
Scout control station (CS) on board LCS but must be passed verbally to CIC (latitude, 
longitude, course and speed) to be manually entered into the COTP. Verbal 
communication can be time consuming and prone to error. Although multiple contacts 
can be passed quickly, this represents a significant limitation to system interoperability 
because they must be manually updated. 

The Merge task is accomplished by operators in CIC and represents the function 
of combining tracks from multiple sources, including the LCS RADAR, into the COTP 
surface picture for the ASUW commander. The Decide task for the ASUW scenarios 
considered is generally delegated via pre-planned response to the operators to transition 
to Phase II classification and identification for all contacts. Additionally, it is understood 
that all unresolved Contacts of Interest (COIs) must be continuously tracked and updated 
until neutralized. 

Delays associated with passing essential Phase I infonnation via verbal 
communications are significant but are not limiting factors for the overall mission 
execution because multiple contacts can be handled simultaneously or in parallel. 


68 



b) Phase II 


Figure 19 represents the function flow of tasks involved in Phase II. As for Phase 
I this FFBD is applicable to whichever asset is assigned with contact resolution 
responsibility, in this case both. Again, it includes the tasks required to ensure that the 
TAO, acting as the ASUW commander, has complete situational awareness and can 
maintain control of the mission. Although the tasks involved in the functional flow 
appear similar to that of Phase I, operator workload and sensor capabilities limit the 
processing capacity to one contact at a time per air vehicle. The serial nature of the tasks 
and the need for human evaluation make Phase II the driver in system performance with 
respect to the MOEs. 


Proceed 



from TAO 


Figure 19: Phase II Functional Flow 

In order to perform the essential mission tasks of classification and identification 
the MH-60 or Fire Scout must detect and acquire each individual contact with the EO/IR 
sensor. The detection can result from direct pointing of the sensor, cueing, or from a track 
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generated in Phase I. With the automated slew capability available for both air assets, the 
time to affect this cueing can be very short and depends primarily upon the 
communication delays in passing a track and the operator’s ability to input the track into 
the system. When the track is self-generated there is very little time delay. The detection 
can also result from a methodical search using various sensor-sweeping patterns when 
there is no asset to provide RADAR tracks for cueing. The associated time delay can be 
very large and depend on many unknown factors like surface vessel traffic density. Either 
means requires the asset to have transited into EO/IR sensor range. The transit delay is 
calculated from the range to the contact, sensor detection range and transit speed. There is 
no associated time delay for contacts already located within the range. A well-prosecuted 
mission will minimize transit delays by coordinating the order of contact investigation 
from the COTP. 

Once a contact is detected in the field of view, the EO/IR sensor operator must 
analyze the image to classify it. The objective of this task is simply to detennine basic 
attributes such as size, type of vessel, and behavior or activity profile. Time to complete 
this task is considered relatively constant for trained operators but additional transit time 
will be required for smaller vessels. For the purposes of this mission, large vessels such 
as tankers, where profiles match the AIS reporting information for commercial traffic, 
there is no additional contact investigation required. 

For all other contacts, the next task of identification must be accomplished. This 
task is also accomplished through analysis of EO/IR imagery but requires closer range 
investigation to observe details leading to assessment of the contact’s potential intentions. 
Therefore, there may be additional transit delay, especially if multiple aspect angles are 
required to obtain identification. A contact that can be positively identified as friendly or 
neutral requires no further analysis. The rest are classified as COIs. These contacts must 
be continuously monitored as potential threats. Depending upon ROE, a hostile act may 
be required to change a contact’s status to hostile and designate it for engagement. The 
preplanned response in the developed mission CONOPS dictates that for any vessel 
identified as a COI, the identifying air vehicle must stay on station until the mission 
commander makes his decision on course of action. The remaining tasks in the Phase II 
functional flow facilitate that decision. 
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The communicate task relays classification and identification infonnation to the 
TAO or ASUW commander in CIC onboard LCS. For the MH-60, information is 
transmitted via UHF verbal communications. In Scenario 1 the MH-60R has the option of 
temporarily assuming the TCDL link from Fire Scout to pass video directly to CIC. 
Though the Fire Scout can use TCDL to transmit video data at all times to the ship, it is 
only received at the UAV control station and must still be verbally passed to CIC over 
internal communications. For both assets, communication delays are significant. 

The next step, accomplished by LCS tactical operators, is the correlation of 
contact classification and identification information with contacts maintained in the 
COTP. This compiled surface picture is the visual representation of the battle space 
available to the mission commander. His decision is the last task in Phase II functional 
flow. After validating the identification he must decide whether to engage and proceed to 
Phase III, or direct the air vehicle to the next contact. This decision will be based upon 
many factors including identification features, relative position and movement to the 
HVA, and ROE in effect. If a COI is left to investigate other vessels, the COI track 
requires close monitoring and an EO/IR revisit schedule is established to ensure its 
profile has not changed. 

c) Phase III 

Due to complexity and situational dependence of potential CONOPS, a detailed 
functional flow was not generated for Phase III. After the initial requirements and system 
architecture analysis, as part of planning the M&S activities to incorporate as part of the 
SE process, the project team decided to concentrate effort on Phases I and II, since the 
greatest benefits of integration and interoperability would first impact the detect, track, 
identify and classify activities during these portions of the mission timeline. To account 
for a complete end-to-end kill chain and to provide a basis for future assessment, the 
tasks involved in conducting a coordinated missile attack were identified and are 
presented in Figure 20. These tasks are ordered and described below, but a full analysis is 
beyond the scope of this report. Time constraints for the project precluded detailed 
modeling and analysis. Detailed analysis in this area is considered a potential candidate 
for follow on work. 
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Figure 20: Phase III Functional Tasks 

d) Quantification of Communication Effectiveness 

The detailed understanding of the information flow and CONOPS provided the 
basis for determining the limitations inherent in the communications architecture. As 
shown in the functional flow analysis, the serial nature of Phase II contact processing 
make that phase the driving constraint. In order to assess system interoperability 
effectiveness with respect to the TTI MOE, the timing associated with each of the Phase 
II tasks needed to be quantified. This analysis was conducted using the given scenario, 
the developed CONOPS, and data gathered from the Stakeholders. Table X shows the 
matrix of assessed time delays for each task in the Phase II functional flow. Times were 
assigned based on the type of contact being investigated. These assignments are general 
rough order estimates intended to represent the average time intervals to complete the 
tasks, independent of sensor ranges. Sensor ranges are compensated for in transit time. 

Ten different categories of surface vessels were defined for traffic that would 
typically be encountered during the given scenarios. The vessels were grouped by size 
as well as interest level based on type of vessel and its profile. Vessels identifiable as 
friendly or neutral are shown in green while hostile contacts are shown in red (in these 
scenarios small armed boats). Vessels that could not be ruled out as hostiles are 
considered contacts of interest and are shown in yellow. The allotted times to accomplish 
Phase II tasks are dependent upon the category of the vessel being investigated. 
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Table 4: Phase II Timing Matrix 



* Contacts classified as COIs require constant RADAR track coverage and revisit with EO/IR; reclassify to 
hostile after scripted profile change 

** Add 2 minutes if cued from external sensor; Add X? minutes to detect if no cueing sensor available 
*** Total time does not include time to transit into sensor range 

The non-contact of interest group consists of the large and medium vessels as well 
as any small vessel that can be positively identified by the sensor operators as 
uninteresting (labeled in table as “fishing”). Following the predetermined tactics of the 
developed CONOPS, certain Phase II tasks can be conducted while in transit to the next 
contact or skipped altogether. These are the tasks that would normally require 
coordination with the ASUW commander prior to moving on to the next contact, shown 
grayed out in the table. 

Two types of large vessels were considered important to reducing the total 
number of contacts must be identified: those reporting themselves via AIS and those not 
reporting were not interesting as threats. A vessel whose classification matched its AIS 
report does not require further investigation. Medium size vessels were also generally 
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considered uninteresting because by definition, they do not match the threat profile of a 
small attack boat. During classification and identification of these vessels it was expected 
that their activity they such as straits transit or fishing, was communicated to the mission 
commander on LCS before proceeding to the next contact. Small vessels without the 
capability to conduct swarm attack such as sailboats and unpowered fishing boats were 
also treated as non-contacts of interest. These, too, were categorized as “fishing” for the 
purpose of the project. 

The rest of the small boat categories were considered hostile or potentially hostile 
contacts of interest. The hostile category contained any vessel that could have been 
visually identified as a threat regardless of its actions; this type of contact was labeled 
with “guns.” The others must have been observed in a hostile act to confirm threat status. 
It is also possible that due to location, a vessel was not approached closely enough for a 
positive identification, for example, a vessel inside territorial waters (TTW). For all of 
these contacts, a decision was required from the ASUW commander before proceeding 
to the next contact, adding significant time to the process because the decision depended 
on time for continuous tracking and adherence to strict criteria to revisit contacts 
identified as COIs with the potential to enter the threat engagement zone. 

The completed Phase II timing matrix for this project provided method for 
quantitatively assessing mission performance. The application of this assessment to the 
interoperability of the Fire Scout and MH-60 in the given ASUW scenarios was realized 
in the sharing of information between assets. This was most noticeable in the time 
required for Phase II detection, which required track information output from Phase I. 
Knowing where to point the EO/IR sensor for cueing was key to reducing timeline. In 
independent operations, a single platform quickly cued its EO/IR sensor directly from its 
own RADAR tracks. In coordinated operations, however, where only one asset has 
RADAR capability per the given scenarios, communication time became critical in 
passing the track information. In this case the detect time was defined to account for that 
communication delay. 

Another mission limitation evident in the Phase II timing matrix was the sharing 
of information with the ASUW commander. The “communicate” and “correlate” tasks 
represent actions required to incorporate classification and identification data into the 
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COTP. This provides the situational awareness that enables tactical decision-making 
regarding threat response in the context of ROE. Therefore, the ability to pass 
information efficiently impacts mission effectiveness. In the timing matrix the 
communicate time directly captures the time delay for passing Phase II information to the 
ship. The decide-time is affected by the quality of information provided; with better 
information a faster decision can be made. 

Transit times, which are not accounted for in the timing matrix, are also impacted 
by data sharing. None of the Phase II tasks can be accomplished until the contact is in 
sensor range. For the asset without RADAR capability, track information must be 
communicated to the operator in order to efficiently direct the vehicle into sensor range. 

In summary, the timing matrix table captured the CONOPS -based logic and 
assumptions about the mission timeline that was later modeled to more effectively 
characterize the impacts of interoperability. 

B. ARCHITECTURE ANALYSIS 

This section describes the Model Based Systems Engineering (MBSE) approach, 
top-level Architecture, Operational Architecture, Requirements Hierarchy, and 
Functional Architecture. MBSE was adopted for the project to gain experience with this 
recommended best practice, which aims to use requirements engineering and modeling 
tools, such as CORE, to enhance the capture, decomposition, traceability and 
configuration control of technical data. This section also contains samples of the 
preliminary CORE Architecture that was developed as part of this project. Graphical and 
textual descriptions of the element relationships and hierarchy diagrams, as well as 
rationale for the architecture model, are included. 

For conducting research on the stakeholder needs and the capabilities of the MH- 
60, Fire Scout and LCS systems, the project team used tools such as system diagrams to 
depict data flow as well as functional flow diagrams. The architecture development 
process translated the outputs of the stakeholder requirements definition and analysis 
processes into functional diagrams and ultimately, alternative physical design solutions. 
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The functional architecture was key in determining how capabilities were 
allocated within a physical system that was already defined. The MH-60, Fire Scout and 
LCS are complete systems in development or deployed. Components of the physical 
architecture were assigned to functions within the functional architecture. Then, the 
constraints on the arrangement of the functional architecture was identified, which 
helped drive the arrangement of functionality into different alternative physical 
configurations. 

The architecture views developed for this project consist of select operational, 
system and technical views that expressed the functional and physical architecture, as 
well as information exchange and net-centric requirements. The project team worked to 
ensure the traceability between architecture views and requirements. 

As part of the Architecture Analysis, the integrated architecture was assessed 
against the stated capability need and requirements for the proposed materiel solution, as 
gathered from the stakeholders. The primary objective was to evaluate the translation of 
operational information into system functionality and preliminary system design 
information, using Enhanced Functional Flow Block Diagrams (EFFBD). A secondary 
objective was to provide initial observations on the model’s utility for follow on systems 
engineering activities. 

Identification of communication and interface requirements were a key 
component for this interoperability project, so it was important to ensure that all internal 
and external interface requirements were properly captured during the requirements 
engineering phase and documented as a part of the architecture development process. 
During this activity, missing, redundant or inconsistent requirements were discovered. 
Follow on efforts related to the architecting process will be required to ensure the 
functional architecture is in balanced with the stakeholder requirements. 

1. Operational Architecture 

The top-level architecture, shown in Figure 21, illustrates the operational nodes 
that have been identified for this architecture. Through the use of CORE, the associated 
operational concept requirements and the guidance and constraints that form the 
framework for this systems architecture were also documented. The operational 
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architecture captured the operational requirements and high level functional analysis in 
CORE, and established major threads through the system. The results culminated in an 
integrated behavior model of the system and its actions. The top-level architecture was 
decomposed hierarchically into the functions performed by the system. These functions 
were identified in direct response to the originating requirements in order to establish 
requirements traceability throughout the model. 
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Figure 21: Top-level Architecture Diagram from CORE 

The top-level CORE Operational and System Architecture was developed by 
referencing the Capability Needs Statement and project OV-1. High-level elements, 
attributes, and relationships were created in CORE. The top-level Architecture contained 
General Elements, Operational Architecture Elements, and Systems Architecture 
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Elements. Once the top-level Architecture was developed, it was further refined by the 
addition of hierarchies for each class. The requirements structure was developed and 
refined by adding requirements elements, attributes, hierarchies, and traceability. 

Given the need to satisfy the operational mission within the context of the 
stakeholder identified operational requirements, the project derived the necessary 
operational behavior for the operational architecture to accomplish the mission or 
missions. This process was accomplished by working with operational activities to 
derive, define and capture key capabilities. Finalized capabilities were integrated to 
become the integrated behavioral model for the architecture. 

This operational architecture achieved a desired effect under specified standards 
and conditions through combinations of means and ways to perform a set of tasks. These 
tasks were a sequence of operational activities (e.g., Discriminate Targets) needed to 
respond to or to provide an external stimulus. 

2. Functional Architecture 

APPENDIX A - FUNCTIONAL DECOMPOSITION shows the top level operational 
architecture structure that was decomposed in order to describe the major functions 
needed to simulate functional operation in a protect LCS from small boat swarm mission. 
Elements, attributes, and relationships were defined to connect the functions to the other 
architecture model elements, as appropriate. The functional sequence needed to 
accomplish the related operational activities was identified. Decomposed structure was 
developed in CORE to create FFBD and EFFBD. Function elements, attributes, 
hierarchies, and traceability were updated and iterated to assemble the final structure. 

The interoperability requirements lead to the derivation of the following top level 
functional diagrams, depicted in Figure 22 and Figure 23, which were used for 
description of activities for Phases I and II of the project CONOPS. 
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Transit: Transit vehicle into position 

Search: Provide/receive tasking to develop track 

Detect: Detect radar return of contact in sensor field of view 

Track: Track entry (manual or automatic) 

Communicate: Pass track to decision maker 
Merge: Add track data to full surface picture 
Decide: Determine course of action 


Figure 22: Phase I Top Level Functions 
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Cue: Provide/receive tasking to ID contact 
Transit: Transit vehicle into sensor range 
Search: Sensor sweep to find contact 
Detect: Discern contact in sensor field of view 
Classify: Determine size and type of contact 

Identify: Determine "hostile", "contact of interest" "white", or "friendly" 
Communicate: Pass contact information to decision maker 
Correlate: Label contact on surface picture with track data 
Decide: Determine course of action 


Figure 23: Phase II Top Level Functions 

These top level functions trace back to the capability need statement and 
operational nodes as well as the capabilities of existing FI-60, LCS, and Fire Scout 
systems/platforms. The CORE model was further refined to identify and define the 
activities, relationships among activities, and the inputs and outputs that have been 
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proposed and allocated to each platform. For example, Figure 24 depicts the 
relationships between SE artifacts for the project. The figure shows how the CORE 
functional architecture was used to link platform sensors as data sources, such as EO/IR 
images and AIS reports, to key mission activities, such as classify and identify, thereby 
defining inputs to these SOS functions. Functional outputs were defined as “target 
classification” and “track ID” - the content of interoperability information exchanges the 
SOS must accomplish. In this diagram, the sample CORE functional view maps directly 
to the functional flow block diagram for Phase II of the CONOPS. The CONOPS FFBD 
laid out the flow of inputs and outputs in context of the complete set of mission activities, 
providing context for identifying key metrics. 
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KEY METRICS 

• Increased Situational Awareness 

• Sensor Detection Range 

• Decreased Time to Detect 

• Decreased Time to Classify 

• Decreased Time to Identify (TTI) 

• Decreased Time to Decide 

• Reduced Search Rate 

• Effect for Engagement 

• Weapons Targeting 

Weight Impact to Air Platforms 


CONOPS Functional Flow Links Functional Architecture for 
Requirements Traceability and Specifications 


Figure 24: Architecture Artifacts and Key Metrics 


Use of the architecture artifacts in this way supported M&S planning and analysis 
for exploring the trade space available in the MH-60, Fire Scout and LCS, as well as 
assessing alternatives. For example, the sample from the CORE functional architecture 
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indicates that where there is more than one sensor contributing input to a function, there 
is a potential to trade off use of one, either or both types of input and the impact to the 
output, as well as the functional segment of activities, may be evaluated for opportunities 
to improve perfonnance and effectiveness (i.e., Does use of ESM speed time to 
classification? If so, is an ESM payload for Fire Scout a feasible option?). 

C. INDIVIDUAL ALTERNATIVES 

Once a set of potential scenarios was defined and analysis of the possible 
solutions completed, the project team defined realistic physical alternatives for the SOS 
communications capabilities within the trade space established by the architecture. These 
alternatives were generated based on knowledge of the current capabilities and 
experience with the platforms. The goal of this effort was to propose physical alternatives 
that when applied functionally to the scenarios would result in improved MOE(s) over 
the baseline. This section provides a description of the physical alternatives. A 
description of the baseline used for subsequent M&S is provided below, as well, for 
reference. 

1. Baseline Physical Description 

The baseline communications configuration consists of the following physical 
components that drive functionality. This configuration can be seen in Figure 25. This 
communications profile is unique to the baseline. 

• LCS with one TCDL channel that can communicate with the Fire Scout or the 
MH-60, but not simultaneously 

• LINK 16 providing communications between the LCS and MH-60 

• Voice channel communications between the MH-60 and LCS, where Fire Scout 
can be used to relay the channel for increased range 

• Voice channel between the Fire Scout CS and the CIC aboard the LCS 
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Figure 25: Baseline Communications Channels 


The baseline also defines the sensor configuration. This sensor configuration is applied 
across all of the Alternatives. Below is an outline of the sensor configuration for baseline 
and all alternatives. 

• MH-60 

■ RADAR 

■ SAR/ISAR 

■ FL1R 

■ Tracks 

■ ESM 

■ IFF 

• Fire Scout 


EO 

FL1R 

AIS 
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2. Alternative-1 


Alternative-1 improves upon the baseline configuration by adding data transfer 
functionality between the Fire Scout CS and the LCS CIC. This communications profile 
is unique to Alternative-1 and can be seen in Figure26. The profile is outlined below, 
highlighted to show the modification to the baseline that distinguishes this alternative. 

• LCS with one TCDL channel that can communicate with the Fire Scout or the 
MH-60, but not simultaneously 

• LINK 16 providing communications between the LCS and FI-60 

• Voice channel communications between the H-60 and LCS with Fire Scout able 
to relay the channel for increased range 

• Voice channel between the Fire Scout control station and the CIC aboard the LCS 

• Datalink between Fire Scout control station and CIC 



Figure 26: Alternative-1 Communications Channels 
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Alternative-1 addresses the KPP of “Minimize Risk to High Value Asset” and attempts to 
improve upon the MOE of “Time to Detect/Classify/ID Contacts”. The impact of 
Alternative 1 on the KPP by Alternative-1 is outlined below. 

Minimize Risk to High Value Asset 

■ Better Situational Awareness for ASUW Commander 

■ Faster Decision Loop for ASUW Commander 

■ Fire Scout Sensor Data shared directly with CIC 

■ H-60 Data Sharing is unchanged 


3. Alternative-2 

Altemative-2 improves upon the configuration of Alternative-1 by adding capability 
to the LCS such that it is able to operate on TCDL with the Fire Scout and MH-60 
simultaneously. This configuration is unique to Altemative-2. This improved 
communication profile can be seen in Figure 27. The profile is also outlined below. 

• LCS with one TCDL channel that can communicate with the Fire Scout or the H- 
60, but not simultaneously 

• LINK 16 providing communications between the LCS and H-60 

• Voice channel communications between the H-60 and LCS with Fire Scout able 
to relay the channel for increased range 

• Voice channel between the Fire Scout control station and the CIC aboard the LCS 

• Datalink between Fire Scout CS and CIC 

• Additional TCDL functionality aboard the LCS - simultaneous MH-60 and 
Fire Scout communication 
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Figure 27: Altemative-2 Communications Channels 

Altemative-2 addresses the KPP of “Minimize Risk to High Value Asset” and attempts to 
further improve upon the MOE of “Time to Detect/Classify/ID Contacts” over 
Alternative-1. The effects on the KPP by Alternative-2 are listed below. 

Minimize Risk to High Value Asset 

■ Better Situational Awareness for ASUW Commander 

■ Faster Decision Loop for ASUW Commander 

■ EO/IR Video Available from both the MH-60 and the Fire Scout. 

■ MH-60S Data Sharing unchanged 


4. Alternative-3 


Altemative-3 improves upon Alternative-2’s functionality by adding a link between 
the Fire Scout and the MH-60. Alternative-3 is broken into two sub-alternatives (3A and 
3B). 3A adds a link that allows viewing of the Fire Scout’s sensor data aboard the MH- 
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60. 3B adds a link that allows both viewing of the Fire Scout’s data aboard and control of 
the Fire Scout sensor payload from the MH-60. This configuration can be seen in Figure 
28. It is also outlined below. 

• LCS with one TCDL channel that can communicate with the Fire Scout or the 
MH-60, but not simultaneously 

• LINK 16 providing communications between the LCS and MH-60 

• Voice channel communications between the MH-60 and LCS with Fire Scout able 
to relay the channel for increased range 

• Voice channel between the Fire Scout control station and the CIC aboard the LCS 

• Datalink between Fire Scout control station and CIC 

• Additional TCDL functionality aboard the LCS 

• Datalink between Fire Scout and MH-60 

o 3A: Fire Scout sensor data is viewable aboard MH-60 
o 3B: Fire Scout is controllable by MH-60 and sensor data is displayed 

Altemative-3 addresses the KPP of “Minimize Risk to High Value Asset” and 
attempts to further improve upon the MOE of “Time to Detect/Classify/ID Contacts” 
over Alternative-2. Alternative-3 also attempts to improve the MOE of “Time to 
Engage”. The effects on the KPP by Altemative-3 are listed below. 

■ Reduced Risk to LCS 

■ Direct Data Coordination between MH-60 and Fire Scout 

■ Improved targeting and engagement 
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Figure 28: Alternative-3A/B Communications Channels 

MODELING, SIMULATION AND ANALYSIS 

Given the nature of the problem statement for this project, the team decided it was 
practical and appropriate to use an M&S approach to gather results on the potential 
benefits of SOS alternatives to improve interoperability. Ideally, using real-world assets 
and scenarios would be the way the gather the best and most informative results. The 
magnitude of effort, however, assets and time required to employ actual MH-60 and Fire 
Scout air vehicles for test in a scenario was not in the project scope. Real-world testing 
could be preformed to add weight and clarity to the results of the modeling and 
simulation effort performed as part of this effort. And the project approach and artifacts, 
including methods and metrics, architecture and models, were developed specifically 
with the intention of later re-use. 

The use of M&S allowed the project team to represent the system while evaluating 
multiple variables, sensitivities, and effects. This approach is extremely powerful when 
attempting to gather statistical data to support analysis. The use of M&S also allowed for 
flexibility in the construction of the scenario and alternatives, leading to the ability to 
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represent a potential physical, real world situation accurately. The use of operations 
research / warfare analysis modeling and analysis aimed to complement the SE approach 
by assess alternatives based on Stakeholder priorities for war fighting effectiveness and 
capability, over SE priorities for ease of integration or degree of re-design and 
qualification for fielded platforms and systems. Additionally, by using M&S, follow-on 
work could be picked up from the initial simulation with little rework required to further 
the efforts that were initiated by the project team. 

This portion of the report elaborates on the modeling approach and the rationale 
for that approach. The alternative physical configurations are described from the 
modeling viewpoint, as well as the scenario for those configurations. Discussion on the 
NSS modeling suite and the relevance to the SE process for this project will also be 
provided. 

A. MODELING APPROACH AND RATIONALE 

The approach to the M&S effort began with discussion on what needed to be 
modeled. It was detennined that the three system alternatives and a baseline 
configuration would be modeled in the context of one scenario. The results of these 
various runs would provide output in the fonn of the previously discussed MOEs for each 
alternative to support analysis and comparison of results. A summary diagram of the 
three alternatives is presented in Figure 29. 


88 



I 





Alternative 1 
MQ-8B - CIC Data link 


Existing TCDL DATA 
Existing LINK 16 DATA 
Existing VOICE 
Proposed Alternatives 


Alternative 3 
MQ-8B-H-60 
Data Cross Link 


Figure 29: Alternatives Communication Channels 


1. Alternatives 

The three alternatives and baseline are shown below in Table 5. These alternatives 
are detailed in an earlier section of this report. Along with the description of the 
alternatives, interoperability enhancements are shown. It is helpful to keep in mind that 
the sum of all portions of time required to identify each contact in the scenario is the 
MOE being investigated through simulation of mission-level modeling runs. 
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Table 5: Alternatives Simulated 


Configuration 

Description 

Interoperability 

Enhancements 

Baseline 

Year 2012 Configuration 

of MH-60 and Fire Scout 

Not Applicable 

Alternative 1 

Addition of link between 

Fire Scout CS and LCS 

CIC 

Fire Scout sensor data 

shared directly with 

CIC/TAO 

Alternative 2 

Addition of one TCDL 

channel to LCS 

EO/IR video to LCS from 

both air platforms 

simultaneously 

Alternative 3 

Addition of video link 

from Fire Scout to MH-60 

Direct data feed from 

Fire Scout to MH-60 


2. Simulated Scenario and Phases 

The baseline and three alternative configurations discussed above were developed 
and studied in a simulation using an environmental scenario that was kept constant. 
Keeping the simulation scenarios constant allowed for all alternatives to be tested against 
the same situation. The scenario is based on the problem statement. 

The problem statement presented the LCS as the HVA traveling through narrow 
straits and surrounded by many vessels, some presumably commercial and private and 
some potentially hostile. The specific concern was that a group of small vessels, possibly 
disguised as fishing boats or another non-threat, converge into a swarm and attack the 
LCS, with the possibility that a single vessel could come close enough to the LCS to 
detonate an explosive device and critically damage or sink the ship. 

The baseline scenario was broken down into three phases, as first described 
previously in this report. The first phase encompassed the activities required for the SOS 
to gain a clear picture of the surface environment based on data gathered on the number 
and location of contacts in the scenario. The second phase consisted of the activities to 
classify and identify these contacts. This phase was the focus of the M&S activity, as the 
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completion of this phase was highly relevant to the MOE. The third and final phase was 
where the SOS engages hostile contacts. Although this portion of the model gathers 
useful data, the analysis was beyond the scope of this project. Planning to address each 
phase is described in the remainder of this section, including a description of the planning 
of the simulation process. 

B. NSS 

In applying the overarching SE process, the project evaluated several M&S options to 
help transition from Stakeholder stated capability gaps and need statements to 
identification and design of an operationally effective and suitable system to meet those 
needs. During the Stakeholder Requirements Definition process, relevant stakeholder 
input was translated into technical requirements and scenarios that could be implemented 
in an M&S tool. The two tools considered were ExtendSim, which had been used in other 
NPS coursework, and the Naval NSS. NSS was identified as the optimum solution for 
this project for a number of reasons including: 

• NSS is the Navy's primary, accredited simulation tool for warfare and operations 
analysis, used by OPNAV and NAVAIR. 

• NSS is an object-oriented simulation that models surveillance, communications, 
tactical picture processing, engagement, sea-based logistics, and C2, including 
explicit modeling of plans and tactics. NSS provides for more explicit, 
characterization and relevant system detail, reflective of a system functional or 
physical architecture. 

• NSS supports developing and analyzing operational courses of action at the 
mission, group and force level. 

• NSS provides the ability to represent the system and evaluate multiple variables, 
system configurations, sensitivities, and their effects. 

• The model and simulation program enables metrics capture and calculation for 
KPPs and MOEs, as well as supporting data elements (i.e., time to identify and 
classify, ranges, etc...). 
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• The simulation enables rapid analysis and evaluation of the differences of 
excursions. 

• The NSS model and simulations are readily available to the project team because 
the NAVAIR Warfare Analysis Department had existing platform models with 
potential re-use for follow-on analysis. 

Based on the above rationale, NSS was chosen as the tool for this project. The 
analysis conducted with NSS helped verify the operational and functional architectures 
for each alternative and provided useful insight into the performance of each alternative. 
Data generated and qualitative analysis through use of NSS contributed directly to the 
AO A conducted for this project. 

C. SIMULATION PLANNING 

1. Logical Flow 

The M&S planning required deliberation about the logical flow of the simulation. 
The initial approach stemmed from the scenario and its phases as discussed early in this 
section and in further detail earlier in this paper. Figure , below, is a flowchart showing 
how the phases of the scenario were addressed by the simulation. 



Figure 30: Planned Simulation Flow 
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This flowchart represents time-flow from left to right. Phase 0 is used to represent an 
entry point, where mission planning occurs. From Phase 0, the simulation began with 
Phase I, represented by the blue line. Phase I operations involved developing a surface 
picture or COTP. The Phase I line intersects at decision point Ai (diamond-shape) that 
allows for branching into another Phase. A decision point may allow for one phase to end 
while another begins or for a new phase to begin while another continues. A decision 
point may also allow for nothing to change unless a specific event occurs to change the 
flow of the timeline. Decision point Ai would branch into Phase II, for example, if 
surface contacts were found within range of the LCS for ship self-defense. Further down 
the path of Phase I, the blue line intersects decision point A n . A n is a decision point that 
represents any number of points in time where a Phase II could begin, based on the 
necessity of making a positive identification of a contact as hostile, for example. A new 
surface target may be located at any point during Phase I operations and therefore present 
the requirement to branch into Phase II. 

The same type of logic was defined for the Phase II line, which is yellow. The 
operations in Phase II dealt with detennining whether a surface target was hostile or not. 
Again, the yellow line can intercept at decision point Bi. Decision point Bi allows for 
branching into Phase III if a target is determined to have hostile intent and is within a 
specified range of the LCS. Just like decision point A n represents any number of points in 
time, so does B n . It is possible, at any point in time in Phase II operations for a target to 
be detennined to be hostile and within range of the LCS. 

The path for the simulation’s conclusion begins when the phases collapse. This 
happens for Phase III once targets are no longer a threat. On the flowchart, this occurs 
where the red Phase III line joins back with the yellow Phase II line. For Phase II this 
happens once all targets have been identified, where the yellow Phase II line joins back 
with the blue Phase I line. Phase I ends once a surface picture has been obtained with 
sufficient or high confidence in its accuracy. At this point, technically, the simulation 
ends. After Phase I there are notional Phase IV and Phase V that handle mission 
assessment and analysis, respectively. This discussion illustrates how the model logically 
addresses the interactions between the SOS and its operational context, embodied in the 
operational scenario as contacts and responses. 
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a) Phase III Complexity 


The main activity in Phase III was to engage contacts that were determined in Phase 
II to be hostile. In the scenario these hostile contacts presented a threat to the LCS and 
must be prosecuted. Because the actions of the Fire Scout and MH-60 are highly 
dependent on tactics and become increasingly complex, the scope of simulating this 
phase was detennined to be beyond the scope of this project. Although NSS was useful 
for assessing alternative effectiveness, it was not designed to simulate weapon 
engagement. The project determined that by gathering the output of the model up to 
Phase II, including the MOE of “Time to Identify,” a reasonable statistical conclusion 
could be made about the impact of each alternative on the time to run the kill-chain as 
defined by the scenario, even though the whole kill-chain was not being simulated. 

2, Modeling Assumptions 

Simulating the actual CONOPS and tactics used in prosecution of the given 
ASUW mission scenarios was very complex. All of the situational dependencies could 
not be effectively modeled. Therefore, it was essential for the project team to develop an 
alternative, representative model that would permit the assessment of mission 
performance relative to the parameters in focus for the project, in this case, the 
communication li nk s that enable the flow of data between the MH-60, the Fire Scout and 
the tactical mission commander in CIC aboard LCS. A key assumption made in the 
development of the simulation was that simplifying the details of the tactics and the 
environmental conditions would not invalidate the simulation results. 

As shown above, “time to identify” was chosen as the key MOE because of the 
desire to assess the efficiency of the system relative to the prosecution of the SWARM 
threat to the LCS. Assessment of the kill chain timeline became the focus of the 
simulation. It was determined that a basic NSS simulation could be used to assess the 
relative effects of communication improvements provided by different alternatives 
relative to the baseline system interoperability. Key modeling assumptions and 
simplifications included: 

• Open water transit versus confined straits transit environment 
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• Fixed number of surface contacts of varying types with random transit profiles 
to simulate congested traffic through the straits transit environment 

• Overlapping, independent and random search profile logic for air vehicle 
versus coordinated sector assignments from the mission commander 

• Simplified threat vessel tactics were not situation-dependent or scripted to 
change during the scenario 

• Contact identification information provided by the air vehicles did not change 
based on vessel profile changes 

• All Phase I surface tracks were generated by the air asset with RADAR 
capability 

• All Phase II classifications and identifications were accomplished by either air 
asset using only the EO/IR sensor (day or night) 

1. Modeling Input Parameters 

In order to assess mission perfonnance using simulation the project team needed to 
determine the critical input parameters. The NSS model produced a simulation 
environment for multiple selected platforms based on user-defined capabilities. Platform 
capabilities were drawn from NATOPS as well as discussions with the program offices 
and experienced operators. Key characteristics included range, endurance, turnaround 
time and speeds used for search and transit. 

a) Sensor Ranges 

For this project it was also necessary to input parameters for the MH-60 and Fire 
Scout ASUW sensors selected for the simplified model. Critical characteristics included 
slant ranges (tangential distance including aircraft altitude) for the RADAR and EO/IR 
sensors. The inputs used in this simulation, shown in Table 6, are approximate values that 
are based on limited program office provided test points and experienced operator 
feedback. Classified information was not included. 

As shown in Table 6 sensor ranges depend on contact size. RADAR capabilities are 
not affected by day or night operations, but there are substantial differences in both the 
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range and coverage between the Fire Scout and the MH-60 sensors. The EO/IR sensor 
range was comparable for both platforms, the modeled input data was the same. The 
clarity of the EO video imagery was significantly improved during daytime operations 
over the infrared imagery available during nighttime operations; sensor identification 
ranges were shorter than for classification because finer details are required to resolve the 
information. While sensor range capabilities were not the focus of this report, they 
defined the required transit time for investigation of contacts. Sensor range impacts on 
performance for classification and identification was a major contributor to the overall 
mission TTI MOE , “time to identify”. 


Table 6: Sensor Modeling Ranges (nm) 



Large Vessel 

Medium Vessel 

Small Vessel 

Day 

Night 

Day 

Night 

Day 

Night 

Detect 

RADAR (MH-60R) 

75 

65 

55 

Detect 

RADAR (Fire Scout)* 

60 

50 

40 

Classify 

EO/IR (Both) 

17 

13 

14 

10 

12 

8 

Identify 

EO/IR (Both) 

12 

8 

10 

6 

8 

4.5 


*120 Degree Coverage 


b) Information Flow Timing Delays 

The other major contributing factor to the “time to identify” MOE was the collection 
and transmission of sensor data between platforms. As discussed in earlier analysis, the 
time delays associated with each task in the information flow are shown in Table 7. 

While it was important to understand the contribution of each subtask component to the 
overall timing, simplified data was required for the NS S model inputs, which are shown 
in the table below. 


96 




Table 7: Baseline Platform Modeling Timing Delays (min) 



Detect 

Classify 

Identify 

Decide** 

Engage 

MH-60R 

0.5 

2 

3 

7.5 

? 

MH-60S 

2.5* 

2 

3 

7.5 

? 

Fire Scout RADAR 

0.5 

2 

3 

6.5 

? 

Fire Scout no 






RADAR 

4 * 

2 

3 

6.5 

? 


*Cued from LCS COTP **Includes communication and correlation time 


Details associated with the contents of Table 7 are provided as follows: Error! 
Reference source not found. Table 8, Table 9, and Table 10 detail the input parameters 
used to model the interoperability improvement alternatives developed for this project. 
Changed parameters are highlighted in yellow. 

Once a contact was detected and in sensor range, the time to accomplish the 
classification and identification was dependent upon operator proficiency, aspect angle 
and contact complexity. Average times of 2 and 3 minutes were used as modeling inputs 
for these activities. 

The “Time to Decide” metric is a roll up of the communication, correlation and 
decide subtasks. This delay was needed to ensure the classification and identification 
details were available to the ASUW commander for decision on tactical response. Since 
actual sensor video data was modeled to be available on board the LCS from the Fire 
Scout, the input time delay was reduced, but only estimated to be about one minute 
because the commander must walk to the Fire Scout CS. Although time to engage was 
not modeled, it was listed in the tables for completeness, but without data. Alternatives 
that improved this time were qualitatively shown with yellow highlights. 

Table 8 provides the modeled time delays for Alternative 1, and shows that the 
detect times for the both assets without RADAR is reduced. In the case of the Fire Scout, 
the track data from the COTP was now available at the control station because of the 
added communication link. Since Fire Scout track data was provided directly to CIC, it 
was more easily shared with the MH-60S reducing sensor cueing time. The decision time 
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was also reduced when Fire Scout video imagery was available at the ASUW 
commander’s watch station. 


Table 8: Alternative-1 Platform Modeling Timing Delays (min) 



Detect 

Classify 

Identify 

Decide** 

Engage 

MH-60R 

0.5 

2 

3 

7.5 

? 

MH-60S 

1.5* 

2 

3 

7.5 

? 

Fire Scout RADAR 

0.5 

2 

3 

5 

? 

Fire Scout no 






RADAR 

1 * 

2 

3 

5 

? 


*Cued from LCS COTP **Includes communication and correlation time 


Table 9 shows the modeled time delays for Alternative 2. The only factor affected 
by this improvement was the scenario-based decision time. In the model, the ASUW 
commander can now see MH-60R video because a second TCDL channel to the LCS was 
opened. The MH-60S cannot take advantage of this capability since it is not TCDL 
equipped. 


Table 9: Altemative-2 Platform Modeling Timing Delays (min) 



Detect 

Classify 

Identify 

Decide** 

Engage 

MH-60R 

0.5 

2 

3 

5 

? 

MH-60S 

2.5* 

2 

3 

7.5 

? 

Fire Scout RADAR 

0.5 

2 

3 

6.5 

? 

Fire Scout no 






RADAR 


2 

3 

6.5 

? 


*Cued from LCS COTP **Includes communication and correlation time 


Table 10 shows the modeled time delays for Alternatives 3A and 3B in scenario 2 
with Fire Scout track data directly cross linked to the MFI-60S. Cueing time for detection 
by the EO/IR sensor was significantly reduced. Although the improvements in 
engagement times were not quantified, the data column is highlighted to show that impact 
of the data cross link. The cross li nk ed EO/IR video data along with laser designator 
indications from the Fire Scout greatly increased the tactical effectiveness of the SOS to 
conduct coordinated Hellfire missile attacks. Time to set-up for ingress, as well as 
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designation communication delays were reduced. The quantification of this data requires 
operational testing and does not lend itself well to simulation modeling via NSS. 


Table 10: Alternative-3A/B Platform Modeling Timing Delays (min) 



Detect 

Classify 

Identify 

Decide** 

Engage 

MH-60R 

0.5 

2 

3 

7.5 

? 

MH-60S 

1 

2 

3 

7.5 

? 

Fire Scout RADAR 

0.5 

2 

3 

6.5 

? 

Fire Scout no 






RADAR 

q* 

2 

3 

6.5 

? 


*Cued from LCS COTP **Includes communication and correlation time 


D. MODELING OUTPUT ANALYSIS 

The project team first investigated the potential operational effectiveness of the SOS 
alternatives by using a static Excel-based model to look at the effect of the assumed 
improved levels of communication and interoperability. The initial investigation using 
this tool was perfonned as a preliminary indicator that the scenario, baseline and 
alternatives were defined sufficiently to achieve the expected outcomes, prior to pursing 
the NSS modeling. From an SE perspective, it was imperative that the models accurately 
incorporate key system, scenario and integration attributes so that outcomes and effects 
were traceable to requirements and key metrics. 

This Excel model was a tool currently used by the NAVAIR Air 4.10 Warfare 
Analysis & Integration Department for other Naval Aviation System analysis projects. 
Recent US Navy studies that utilized this tool included an effectiveness analysis of the 
Coast Guard’s C-130J aircraft, the P-3C, and a P-8 High Altitude ASW effectiveness 
study. Based on this experience, the project determined this model could be useful for an 
initial effectiveness assessment of the alternatives, highlighting comparisons against the 
baseline. To employ the Excel model, the search effectiveness metrics for “Search Rate” 
and “Time to Search” for the Fire Scout and MH-60 variants and alternatives scenarios 
were used. This investigation resulted in an initial effectiveness estimate, providing 
assurance that further and deeper analysis and more complex modeling would provide 
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useful outcomes. The SOS Baseline and the three Alternatives were investigated with 
this Excel model: 

• Alternative 1 - Fire Scout with an improved cross-link to the LCS CIC 

• Alternative 2 - Fire Scout with TCDF and MH-60 with TCFD, using both 
available FCS compatible data link channels 

• Alternative 3 - Fire Scout and MH-60 with compatible data li nk s for 
communication supporting MH-60 sensor data transfer and sensor payload control 
of the Fire Scout. 

Model inputs for the scenario included: shipping density (ships per square mile), an 
average EO/IR sensor range (nautical miles), Search Area (square miles), and average 
Time to Classify a contact (Minutes), a time represented by a roll up of detect and 
classify time delay assumptions. The baseline input was the initial time delay assumption 
representing the current communication capability. 

1. Search Rate Results 

Summary results of each case described above indicated that search rates 
increased for each alternative over the base line and also increased from progression of 
Alternative 1 to Alternative 3. A sample of model results for the Baseline, Alternative 1 
and Alternative 3 are presented in Table 11. Figure 31 provides graphic illustration of the 
time for the search rate, identification delay and time required to clear the specified area 
of interest as an example, for the MH-60S working cooperatively with the Fire Scout. 


Table 11: Output Data from the Search Rate Model 



MH-60/Fire Scout 

Link 

CS Link to CIC 

Baseline 

Alt. 3 

Baseline 

Alt. 1 

MH-60S 

ID Delay (min) 

4.5 

3.0 



Search Rate (nm/hr) 

1906 

2175 



Time to Clear Area (hr) 

11.34 

9.93 



Sorties Required 

4 

3 
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MH-60S 

ID Delay (min) 



4.5 

3.5 

Search Rate (nm/hr) 



1906 

2077 

Time to Clear Area (hr) 



11.34 

10.4 

Sorties Required 



4 

3 

Fire 

Scout 

ID Delay (min) 



6.0 

3.0 

Search Rate (nm/hr) 



1596 

2014 

Time to Clear Area (hrs) 



13.53 

10.72 

Sorties Required 



2 

2 



Figure 31: Graphical Comparison of Search Rates - Baseline vs. MH-60S and Fire Scout 

Specific improvements to search rates for Alternative 1, where the Fire Scout CS 
and LCS CIC were integrated with a data link, the Fire Scout search rate improved about 
26% and the MH-60S search rate improved about 9%. And for Alternative 3, Fire 
Scout and MH-60S integrated with a C2 link for the sensor payload, the MH-60S search 
rate improved about 14% . This type of data confirmed the initial assumptions for the 
project. Because the Search (Surveillance) Rates for the MH-60S, and Fire Scout 
improved with Alternatives 1 and 3, the project team was confident to proceed with more 
complex modeling. 
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2. Time to Search 


The second performance metric utilized from the model was the ‘Time to Search’. 
This figure represents operationally how fast a search platform can cover a defined area 
of interest. This measure is important because in an operational environment, the ability 
to search an area in the shortest amount of time provides commanders with critical 
situational awareness necessary for tactical decisions. Additionally, finding a hostile 
contact early reduces risk for all friendly platforms and increases the variety of options to 
deal with the risk. Model runs were perfonned for the same alternatives as in the Search 
Rate calculations. Raw results for ‘Time to Search’ are shown in 11, above. A graphical 
representation of the results follows in Figure 3 in comparison with the baseline. 



Figure 32: Time to Search an Area 

Results indicated that time to clear the operational area, measured in hours, decreased for 
all SOS alternatives. Specifically, for Alternative 1, the Fire Scout CS link with the LCS 
CIC, the Fire Scout Time to Search improved by about 27% and the MH-60S improved 
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by about 9%. For Alternative 3, the Fire Scout and MH-60S linked for C2 of the sensor 
payload, the MH-60s Time to Search is improved by about 14% . 

In additional to Time to Search improvements, Alternative 3 reduced MH-60S 
sorties required to search the box by 1 sortie. This reduction could be significant in terms 
of cost and manpower required to perform the mission. In the current environment of 
fiscal constraints, this result could be a basis for additional analysis. This result is similar 
to the findings of the Aviation mix study that preceded the project '■ 10 l This data also 
supports the assumptions for the project and confirmed the value of more complex 
modeling finding similar trends. 

3. NSS Model Analysis and Starting Inputs 

Having confirmed the predicted interoperability improvements for a sample of the 
project alternatives using the Excel model, more complex modeling was executed to seek 
results using a more dynamic simulation that addressed the CONOPS more explicitly, 
including probabilistic tactics. This analysis was perfonned by using NSS to build a 
mission level model and emulate the operational scenario defined by the stakeholders. 
Model planning and development required three months of project team interaction with 
an expert NSS modeler, with two months of iteration on inputs and assumptions to refine 
observed data outputs. Figure 33 presents a sample screenshot from the NSS model 
display, showing the NSS input mode for region and track data. Additionally, Appendix 
B provides a collection of NSS screens as an overview of the model features, structure 
and sample content employed for this research. 
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Figure 33: NSS Input Mode Display for Regions and Tracks 

Entity behaviors were programmed into the NSS model to populate the simulated 
operational environment. Platform capability data researched and documented in this 
project was used to populate entity behavior fields of the model. As a lesson-learned, the 
project team observed that SE artifacts such as functional and physical architecture views 
and FFBDs are useful, but do not translate directly, to the format and rules for 
programming the mission modeling tool. As evidenced by the investment in dialog 
several months, the use of warfare analysis in support of SE demands significant effort to 
ensure consistency and utility in order to achieve the benefit of operational context 
informing the SE process. 

The modeled entities consisted of blue forces: one LCS, one MH-60R or MH- 
60S, and one Fire Scout with and without RADAR, as well as neutral and red forces 
consisting of 65 ships. The blue platfonn and sensor performance characteristics, 
previously identified in the current capabilities section of this paper, were the baseline 
inputs to the model’s database of required entity characteristics. Additional 
characteristics input into the entity behavior fields of the model were the platfonn 
functions of detect, identify, and classify and estimates of time required to accomplish 
these activities. These characteristics were the assumed delays times associated with 
communication flows and improvements to those as described by the project alternatives. 
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Neutral and red contacts were represented in the scenario for shipping traffic and 
probable SWARM hostiles. The neutral entity characteristics consisted of contacts of 
various sizes, large, medium, and small, as defined by a RADAR cross-section data 
element. These characteristics represented real-world shipping traffic that would be 
encountered by Naval Forces in a geographic region where a SWARM threat could 
occur. Large, medium, and small entities equated to tanker or commercial sized shipping 
and fishing or hostile traffic. These three classes of ship platform in the simulation were 
also given varying speeds of performance and model tags for neutral or hostile. It is 
important to understand that these model tags of hostile or neutral drove whether an air 
platform needed to do more than just detect the contact or needed to identify and classify 
the contract. Critical Contacts of interest (CCOI) were tagged to all hostile contacts and 
various other small contacts. The hostile or neutral tag then forced the behavior of the air 
platform to follow the delay times associated with the communication structure for each 
alternative. It was decided that there could be no other sensor used for detecting or 
classifying due to the additional time it would require in constructing and refining the 
model; ESM would not be used but recommended for follow on study. For all model 
runs, all detections were accomplished via RADAR and EO/IR sensors. 

Twenty-five hostile entities were sized as small vessels and were given random 
speeds from 0 to 45 knots. Other model behaviors and CONOPS input into the model 
consisted of: 24 hour flight operations with both blue air assets flying during the 
periods of transit; and real-world endurances, re-fueling, and delays associated with 
landing and taking off from the LCS. Simulating a transit of a straight, the LCS was 
programmed to transit the operation area at 15-20 knots. For search tactics, blue air 
assets were programmed to search in front of the LCS and return to intercept any 
unknown entity that approached the LCS within 5 miles. Additionally, to introduce more 
realism, the simulation-based COTP contacts were programmed to expire if any contact 
did not have a blue sensor on it for more than 30 minutes. This simulation rule meant if 
all blue assets lost contact of a previously detected contact for more than 30 minutes the 
contact reverted to an unknown contact needing re-detection, identification, or 
classification. 
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a) NSS Model Run # 1 


The scenarios run for the first NSS model run were for a MH-60R paired with 
non-RADAR capable Fire Scout and a RADAR capable Fire Scout paired with an MH- 
60S. Flight operations began as the LCS transited the simulated straights and the 
platforms were to detect, identify and classify contacts to guard against a SWARM threat. 
Again, both air vehicles were airborne continuously for the scenario and began search 
operations in front of LCS. This was run for the baseline case, with no communication 
improvements, and alternatives 3A and 3B. These three model runs were performed 100 
times each to produce statistically significant data and confidences. The summary results 
of these runs are given in Table 12. 


Table 12: Output from First Run of NSS Model 




Baseline 

MH-60S & 

Fire Scout-R 

3a 

MH-60S & 

Fire Scout-R 

3b 

MH-60S & 

Fire Scout-R 

Baseline 

MH-60R 

& Fire Scout 

3a 

MH-60R & 

Fire Scout 

3b 

MH-60R & 

Fire Scout 

MH-60S 

Detect 

7.67* 

7.10 

6.72 





Class 

9.17 

8.56 

8.71 





Identify 

9.52 

9.53 

9.48 




MH-60R 

Detect 




6.83 

6.81 

6.37 


Class 




8.65 

8.68 

8.83 


Identify 




9.11 

5.85 

8.52 


* - All units in Hours 


Figure 34, Figure 35, and Figure 36 show the relationships between “Time to Detect,” 
“Time to Classify,” and “Time to Identify” for the baseline case and each 
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Altemative/Scenario in hours. Times are averages of the combined MH-60 and Fire 
Scout mix for each scenario. 


b) NSS Run #1 Analysis 

The data and graphs produced for the first NSS run confirmed trends, but did not 
completely validate the project hypotheses. While improvements in the air platform 
search functionality from improved communications were evident, the results were 
inconsistent. Figure 32 does shows a decrease in “Time to Detect” for both alternatives 
3A and 3B as compared to the baseline. The best result, however, was the MH-60S 
“Time to Detect” result shifting from 7.67 hours to 6.72 hours with alternative 3B. The 
MH-60S result is almost a reduction of an entire hour to do all required detections. This 
would be a significant advantage in an operational scenario. 



Figure 34: Time to Detect (hrs) - Reducing Trend 


Figure 35, below, shows the Excel model predicted decrease in “Time to Classify” for 
Alternative 3 A, defined for Level of Interoperability 2 (LOI-2) with the MH-60S 
receiving Fire Scout sensor data, and Alternative 3B, defined for Level of Interoperability 
3 (LOI-3) with the MH-60S receiving Fire Scout sensor data and controlling the Fire 
Scout sensor payload, as compared to the baseline case. The “Time to Classify” at LOI- 
3 for MFI-60S increased as compared with LOI-2, but the cause of this unexpected longer 
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duration is not discemable based on the modeling. For the MH-60R, the “Time to 
Classify” also increases for all cases when compared to the baseline case. Further study 
is needed to understand the system interactions and effects. The MH-60S is lower than 
MH-60R for the LOI-2, but higher for LOI-3 and the Baseline case. Although the results 
do not completely match the expectations or predictions from the Excel model, and 
appear inconclusive, they are consistent with trends in keeping with the project top level 
objectives. This confirmation is useful for Stakeholders deciding to expend resources on 
more costly, but informative, analysis and assessment. 



Figure 35: Time to Classify (hrs) 

The final performance metric in run #1 was “Time to Identify.” Figure 36 shows a 
marginal increase for Alternative 3A (LOI-2) for the MH-60S when compared with the 
Baseline case but significantly the MFI-60R shows a decrease in “Time to Identify” for 
LOI-2 and LOI-3, when compared with the baseline. The MH-60R reduction of Time to 
Identify from 9.11 hrs to 5.85 hrs was the best improvement of all the scenarios. 
Identifying all required contacts 3 hours faster would provide an operational commander 
with a huge tactical advantage. 
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Figure 36: Time to Identify (hrs) 


c) Model Inconsistencies 

For several runs the results could not explain the lack of predicted improvement 
in alternative 3B as compared to 3A. Model results did show an improvement for 
alternative 3 A (LOI-2) over the Baseline for the MH-60R/Fire Scout without RADAR, 
but it did not show any significant improvements elsewhere. The team spent extensive 
review time with the model raw data to determine why the predicted results did not 
appear. It was detennined that possible NSS programmed behaviors may have been the 
reasons why. It was also observed that currently, there is no experience in the Navy with 
LOI-3 manned-unmanned system integration, so specific functionality and expected 
performance is unknown. (Research found that the closest example of comparable 
capability is the long-standing capability of the Aegis ship CIC to command SH-60B 
sensors over Hawk Link, but that example was not explicitly addressed by the project 
modeling. Modeling that behavior for this purpose may inform future manned-unmanned 
integration opportunities. ) Some of the indicators and reasons for the NSS outcomes 
impacting the project include: 

• In several instances air assets at the geographic extremes of the scenario 
returned to the LCS to identify a contact that was entering within the 5 mile 
exclusion zone of the ship even though the other air asset was closer. The 
team identified this as unrealistic. 
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• In several instances the 30-minute expiration of contact knowledge for 
contacts that had no blue sensor tracking did not seem realistic. Some 
contacts were “dead-in-the-water” and had not changed geographically, but 
were subject to the re-detection and identification rule because a sensor was 
not in continuous contact. The team deemed this unrealistic as well. 

• For some model data elements, the project team noticed that some contacts 
were being identified more than once by the same air asset when it had not 
previously lost contact. The team believed that this was unrealistic in that 
contacts identified by an air asset or air crew would not have been identified 
more than twice within any sortie, especially if they never lost contact with a 
sensor. 

NSS communication behaviors were cited as a possible cause of why air assets naturally 
identified contacts that were closest to them but in other instances they did not. This NSS 
model capability was deemed suspect because the team did not have enough time to 
ultimately determine if it was working correctly. Despite the reasons for the data not 
completely aligning and validating assumptions, the team believed results did identify 
improvements due to improved communications architectures. The NSS modeling 
confirmed the basic expectations and indicated consistent trends where the behaviors of 
the systems were well understood and the modeling reflected that detailed definition of 
system performance and interactions. 

d) NSS Model Run #2 

This model run took lessons learned from model run #1 and attempted to correct 
errors and inconsistencies. Mindful of the irregularities of identified model behaviors 
cited above, model behaviors were modified for this run to correct them for realism. In 
this run the 5-mile exclusion zone around the ship was removed to alleviate air assets 
from unrealistically retuning to identify a contact that either the LCS could have 
identified using own-ship sensors or a closer air asset could have identified. The model 
was altered to keep the COTP constant for the entire model run. This alteration removed 
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the 30-minute expiring contact rule when no blue senor was not in contact with a target 
for greater than 30 minutes. This alteration attempted to correct unrealistic double 
contact detection behaviors observed in the first run. Another alteration to the NSS 
model was to have contacts only identified once between air assets as the levels of 
communication improvements increased. This alleviated some minor tactical behavior 
inconsistencies seen in the first run. The final alteration made to the model was the 
removal of the NSS communications logic behaviors as part of the base model. This 
capability was inherited from a baseline model that the project modified at the start of the 
project. Removal of this NSS capability from the scenario was done because the team 
could not identify if it was working properly. The effect of this removal was that all 
model detect, identify and classify outputs were based solely on the assumption delay 
times presented earlier in the paper. 


e) NSS Model Run #2 Analyses 

The outputs of this run were made with alterations to the model to correct 
inconsistencies from model run #1. Results for the run, however, did not show much 
improvement from run #1. Although Alternative 3B had a higher predicted improvement 
from the initial Excel based model, NSS results showed that alternative 3B was 
consistently the worst perfonning of the alternatives. This was backward and completely 
opposite of the expected result and seemed indicative that another error may have been 
introduced during alterations from the first run of the NSS model for this alternative run. 
The reasonable expectation was when the MH-60 could actively control the Fire Scout 
sensor payload real-time, contacts would be prosecuted more efficiently and with greater 
benefit to the COTP. Lack of time and access to the source model prevented diagnosis 
of the root cause problem and prevented correction. The NSS modeler it was not 
uncommon that such analysis often takes many months to rid the model of bugs. Run #2 
though did show areas of promise - confirming the utility of the project endeavor. 

Figure 37, Figure 38 and Figure 39 show the relationship between “Time to 
Detect,” “Time to Classify,” and “Time to Identify” for the baseline case and each 
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scenario in hours. The times are averages of the MH-60 and Fire Scout mix for each 
scenario. Table 13 is the raw data used to produce the bar graphs. 


Table 13: NSS Model Second Run Output Data 



Option 1 

Option 2 

Option 3b 

Option 1 

Option 2 

Option 3b 

MH-60S 

Detect 

3.64 

3.74 

4.16 




Class 

4.64 

4.77 

3.67 




Identify 

4.80 

4.95 

5.02 




MH-60R 

Detect 




3.76 

3.74 

3.85 

Class 




4.54 

4.57 

4.73 

Identify 




4.70 

4.71 

4.48 


Unpredictably, “Time to Detect” showed a reversal in improvement for the MH-60S and 
RADAR Fire Scout and for the MH-60R with the Fire Scout not equipped with RADAR. 
Again, Alternative 3B was consistently higher than Alternatives 1 or 2 and that remained 
unexplained for the analysis of the run. It is possible that an error connected to the 
alterations made to the model from run #1 to run #2 may have occurred. All data from 
this ‘Time to Detect’ metric lacked confidence to make conclusions. 



Figure 37: Time to Detect (hrs) 


112 


























“Time to Classify” data illustrated in Figure 34 did not show any similarity to the project 
team’s predictions or expectations, except for the MH-60S. No change was noted for any 
alternative except for Alternative 3B for the MH-60S. For the MH-60S and Fire Scout 
without RADAR, Alternative 3B showed reduced “Time to Classify” by over an hour. 
This result would seem plausible since the MH-60S currently has no RADAR or a data 
li nk back to the ship. Alternative 3B would give some of those advantages. 



Figure 38: Time to Classify (hrs) 

Figure 39, “Time to Identify,” like “Time to Classify,” displayed some irregular 
behaviors. Although the improving communication architectures showed worse 
performance for the MH-60S and RADAR equipped Fire Scout, there were minor 
improvements for the MH-60R operating with the Fire Scout not equipped with RADAR. 
The MH-60R and Fire Scout without RADAR improvement amounted to 12 minutes 
better for Alternative 3B versus Alternative 1 or 2. 
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Figure 39: Time to Identify (hrs) 


4. Modeling Difficulties 

The complexity of the NSS model was a difficulty the team needed more time to 
work out. The team was dependent on the professional NSS modeler who was 
unavailable at various times of the project due to his workload. The NSS model, though 
complex, produced large quantities of data that would be necessary to properly perform 
quality analysis. The team accepted the power of the mission-level model as the right 
tool for determining the effectiveness of alternative designs through simulation. As 
mentioned earlier, the NSS modeler that assisted the team noted that studies of the 
complexity level that the team undertook, usually takes 8-10 months of dedicated model 
work to fully complete runs and produce analytic results. 


5. Modeling Conclusions 

The team concluded that several model output results were consistent with the team’s 
original hypothesis. The trade space for communication path improvements, as described 
by the architectures of Alternatives 1, 2, and 3, had data throughout the various runs that 
did support predicted improvements and the initial assumptions outlined in the time delay 
tables. Because of the data irregularities, however, the team at best can only deduce that 
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some improvement does exist for Alternatives 1, 2, and 3 and more modeling is required 
to completely define it. The Excel model that was performed at the start of the analysis 
phase is one artifact that suggests that up to a 26% improvement may be possible. This 
tool also predicted that Alternative 3B would facilitate the most improvement to air 
platform search functions, as did NSS model run #1 results for “Time to Detect” and 
NSS model run #2 results for “Time to Identify” for the MH-60S and Fire Scout 
equipped with RADAR. With this knowledge, further analysis is warranted as 
Alternative 3B may be still the most significant future work for further study. 


V. ANALYSIS OF ALTERNATIVES 

A. ALTERNATIVE UTILITY SCORING 

Analysis of the effectiveness of the project alternatives involved a combination of 
three different research approaches: 1) review and analysis of literature, program and 
technical publications; 2) use of an Excel based static model; and 3) use of the NSS 
dynamic simulation model. Each of these analyses and their results produced 
information that collectively was used to arrive at an overall effectiveness score for each 
Alternative. This effectiveness score is referred to in this section as the Alternative 
Utility. Utility analysis was selected as the method for scoring alternatives because is a 
common and recognized approach with credentialed foundations in academia/ 131 Utility 
scoring of the alternatives for this project was accomplished by evaluating the three 
alternatives against key metrics and those evaluations were supported by one of the three 
analysis approaches. The mission scenario decomposition identified the functional needs 
for the SWARM scenario, discussed earlier in the report. The key metrics were derived 
from an analysis of the necessary operational and functional requirements derived from 
the mission scenarios and CONOPS, and further confirmed by project stakeholders using 
the method described previously in the report and depicted in Figure 24. The key metrics 
chosen for utility scoring were: 
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1. Situational Awareness of the ASUW Commander 

2. Time to Detect/Classify 

3. Time to Identify/Decide 

4. Search Rate 

5. Effect for Engagement (Weapons Targeting) 

6. Weight Impact to Air Platforms 

1. Discussion of Key Metrics 

Improvements to the SA of the TAO aboard LCS or the Battle Group’s ASUW 
Commander were identified early in the project by the stakeholders as an important 
outcome and motive for defining SOS alternatives and interoperability improvements. 
Reducing the time to detect and identify threats and to plan a course of action that could 
include ordering a strike on hostile targets meant the difference between loss of life and 
ship or a successful defense. For this reason SA was chosen as the highest-level 
discriminator for scoring and comparing the alternatives. Better understanding the 
tactical situation more quickly, earlier in the mission timeline, can give commanders 
more options to complete the mission successfully. An evaluation of the alternatives 
against this key metric was supported by the literature studies. 

Next, performance of the platfonn systems quantified by estimating the amount of 
transferred tactical information and the effect to reduce the unknowns of a tactical 
situation was another aspect for evaluation and scoring. Improved performance over the 
perceived status quo was a priority for the project stakeholders and recognized as a 
benefit for prosecuting a SWARM scenario. Key measures of performance were defined 
for “Time to Detect/Classify,” “Time to Identify/Decide,” and “Search Rate.” These 
measures of perfonnance were quantified using the Excel based model and NSS. 

Next, the “Effect on Engagement” key metric was chosen to evaluate the weapons 
employment capability of the platforms and the effect the alternatives had on determining 
mission success. The assessment of this key metric was supported by the project team’s 
literature study and the application of that understanding to the operational scenarios. 

This key metric’s specifics were based the relevance of each alternative to get reliable 
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targeting infonnation to the MH-60 platform or LCS in order to successfully eliminate 
hostiles. 

Although not a metric directly addressed by the project stakeholders, the project 
identified the final key metric, “Weight Impact to Air Platforms” as an important systems 
engineering concern. Analysis of technical and program publications identified that a 
key constraint to the implementation of any alternative would be the addition of 
equipment that added excessive weight to either the MH-60 or more critically, the Fire 
Scout. Additional weight on an air platform drives up cost for integration and operations 
and may become prohibitive from a technical and a program perspective. 

The alternatives were evaluated to determine their ability to improve targeting 
information. In various alternatives this amounted to the difference between passing 
targeting data via voice channels, as in the case for Alternative 1, and passing all 
targeting data digitally, as in the case of Alternatives 2 and 3. Any ambiguity in targeting 
information could have serious safety and mission impacts. Voice communication, 
providing information describing what target to shoot, for example, was judged to be 
more prone to ambiguity, error and delay than digitally transmitted latitude and longitude 
coordinates or a visual image of the target. Although this determination was subjective, it 
was informed by an understanding of Human System Integration (HSI) and supported by 
stakeholder opinion. 

The final preferred value used in assessing the alternatives was the “weight impact to 
air platforms.” This measure is as much a topic of operational concern as an area of 
engineering concern. Weight impacts air platform flight performance and the desire to 
achieve maximum onboard capability as has historically pushed every current Navy air 
platform to strict weight growth monitoring and management programs. Weight limits 
are critical design constraints for UAVs. Weight is a key cost estimating parameter. The 
current history of weight growth of air platforms and the effects warrant that some 
attention be given to this value. Absence of this value could result in an air platform 
having to trade fuel to incorporate the hardware, which has a negative effect on 
endurance and combat radius, depending on the alternative chosen. All the alternatives 
were evaluated based on their estimated weight risk to the MH-60 and MQ-8. This 
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subjective assessment was supported by program subject matter expertise and literature 
study. 

2. Utility Scoring 

The next step in the utility scoring process was evaluation of the alternatives 
against the key metrics. Raw scores from analysis data were used where available and a 
numerical value of 1, 2, or 3 points was assigned qualitatively to each alternative based 
on the project research and interpretation of M&S results. Using the qualitative measures, 
3 points were given for the alternative demonstrating the most improvement and 1 point 
was given for a characteristic that was no better than a current, unmodified characteristic. 
Table 14 provides a summary of scoring criteria and preferred values. 


Table 14: Utility Scoring System 


Attribute 

Least 

Middle 

Best 

SA of ASUW 

Commander 

1 point for no change or 

worse than status quo 

2 points for an 

improvement over 

current configuration 

3 points for movement 

of both air platforms 

information to ship 

digitally 

Time to 

detect/classify 

Normalized Raw score 

based on Table 13 

Normalized Raw score 

based on Table 13 

Normalized Raw score 

based on Table 13 

Time to 

identify/decide 

Normalized Raw score 

based on Table 13 

Normalized Raw score 

based on Table 13 

Normalized Raw score 

based on Table 13 

Search rate 

Normalized Raw score 

based on the Excel results 

Normalized Raw score 

based on the Excel results 

Normalized Raw score 

based on the Excel 

results 

Effect for 

engagement 

1 point for no change or 

worse than status quo 

2 points for an 

improvement over 

current configuration but 

not weapons quality data 

3 points for passing 

weapons quality 

targeting data 

Weight impact to Air 

platforms 

1 point if weight risk of > 

501bs 

2 points if weight risk is 

lOlbs < risk < 50 lbs 

3 points if weight risk 

is <101bs 
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After determining the alternative raw scores using the table’s scoring rubric, a 
nonnalization of the scores was accomplished to determine a final utility score for each 
alternative. In nonnalization, raw scores were translated into a value from 0 to 1 relative 
to the best and worst scores and the prefened value. Normalization facilitated easier 
comparisons of alternatives. Finally a weighting factor was applied before aggregating 
the scores for each alternative and calculating the final utility value. 

3. Weightings 

Because the preferred alternatives represented the project stakeholder needs and 
derived requirements for executing the ASUW SWARM mission successfully, the 
preferred attributes were interpreted as priorities of value. The mass property or air 
platform weight attribute was not equal in importance to the SA of a warfare commander 
for example. To address the true priorities, a group of operational users were asked to 
prioritize the attributes. Priority weights were defined and applied to the nonnalized 
preferred value scores for each of the alternatives. Table 15 presents the operator- 
defined weightings that were applied to the final scores of the preferred attributes for all 
alternatives. 


Table 15: Attribute Weighting 


Attribute 

Scoring Weight 

SA of ASUW Commander 

20% 

Time to Identify/Decide 

25% 

Time to Detect/Classify 

15% 

Search Rate 

15% 

Effect on Engagement 

15% 

Weight Risk to Air Platforms 

10% 


The weighting table above shows the importance operators placed on the 
performance of an SOS alternative, which was confirmed over the course of the project 
by stakeholder comments throughout the project and mission analysis. The preferred 
values of Time to Identify/Decide, Time to Detect/Classify, and Search Rate represented 
55% of the total weighting of a final alternative’s score. Moreover, this combined 
weight was supported by the M&S results. The preferred values of SA of the ASUW 
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CDR, Effect on Engagement, and Weight risk to air platforms were supported by the 
project’s literature studies and other accomplished research that provided the academic 
basis from which to make judgments and draw conclusions. 

4. Utility Scoring Results 

The following sections describe the results of the utility scoring for the SOS alternatives. 

a) MH-60S and RADAR Equipped Fire Scout 

Based on the scoring method described above and the nonnalized scores, Table 16 
presents the results for the MH-60S operating with the Fire Scout equipped with 
RADAR. The results support the conclusion that any of the alternatives improve 
performance over the fielded baseline. The results favored Alternative 1 over 
Alternatives 3A and 3B. 


Table 16: MH-60S and RADAR Equipped Fire Scout Scores 


MH-60S/RADAR Fire Scout 

Baseline 

Alternative 1 

Alternative 2 

Alternative3A Alternative 

Situational Awareness 

0.07 

0.20 

0.13 

0.07 

0.07 

Time to Detect/Classify 

0.00 

0.17 

0.00 

0.25 

0.25 

Time to Identify/Decide 

0.00 

0.15 

0.00 

0.00 

0.00 

Search Rate 

0.14 

0.14 

0.13 

0.15 

0.15 

Engagement Factor 

0.05 

0.05 

0.05 

0.10 

0.15 

Mass Properties 

0.10 

0.10 

0.10 

0.03 

0.03 

Weighted Final Scores/Utilities 

0.35 

0.81 

0.41 

0.60 

0.65 


b) MH-60R and Fire Scout without RADAR 

Table 17 provides the results for the aviation mix of an MH-60R equipped with 
RADAR operating with Fire Scout without RADAR. These results indicated 
Alternatives 1 and 2 were an improvement over the fielded baseline configuration, but 
Alternatives 3 A and 3B were not. Based on this data, Alternative 1 or 2 would be 
recommended before Alternative 3. 
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Table 11: MH-60R and Fire Scout without RADAR Scores 


MH-60R/ Non RADAR Fire 


Scout 

Baseline 

Alternative 1 

Alternative 2 

Alternative 3A Alternative 3B 

Situational Awareness 

0.07 

0.20 

0.13 

0.07 

0.07 

Time to Detect/Classify 

0.00 

0.25 

0.00 

0.00 

0.00 

Time to Identify/Decide 

0.00 

0.09 

0.15 

0.00 

0.00 

Search Rate 

0.12 

0.15 

0.12 

0.12 

0.12 

Engagement Factor 

0.05 

0.05 

0.05 

0.10 

0.15 

Mass Properties 

0.10 

0.10 

0.10 

0.03 

0.03 

Weighted Final Score/Utilities 

0.43 

0.84 

0.55 

0.32 

0.37 


It should be noted that the NS S model structure should be investigated and modified 
before accepting these results completely for decision-making. 


c) Conclusions 

The utility scoring results for the different aviation mixes indicated that either 
Alternative 1 or Alternative 2 provide greater potential mission improvement and may be 
recommended over Alternatives 3A and 3B. Alternatives 3A and 3B were predicted and 
expected to show a greater utility, but M&S inconsistencies could not be resolved to 
provide needed confidence in the results. It should be noted that the contribution of 
improvements to weapon employment and threat engagement were not evaluated due to 
limitations in project scope and modeling. It can be concluded, however, these SOS 
alternative architectures were all predicted to improve the preferred attributes over the 
current fleet proposed configurations and the utility scoring confirmed this trend. 

B. CRITICAL ASSESSMENT OF ALTERNATIVES 

Table 18 presents the formal definitions of UAV C2 interoperability from the Fire 
Scout NATOPS Manual 1 lxl , based on the mandated international standard for UAV C2, 
STANAG 4586. f211 These definitions were used as the basis for assessing the specific 
technical engineering details for functional and physical integration of the SOS 
alternatives into the design baselines of the MH-60, Fire Scout and LCS. 
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Over the course of the project three alternatives for MH-60 and Fire Scout 
interoperability were defined, modeled and evaluated. Each alternative was an 
independent implementation of a capability that directly impacted air asset 
interoperability during a combined sortie. The alternatives were technically autonomous 
and could be realized alone or as was later determined, in combination. Based on the 
findings of this research, increased mission capability is expected from an SOS 
alternative that improves interoperability. 

This critical assessment addresses the engineering necessary to achieve the SOS 
alternatives. While a complete analysis would encompass the entire lifecycle of each 
implementation, manpower issues and logistic factors were not addressed directly by this 
research. Although these factors directly affect the employment and supportability of air 
assets on the LCS, they were not influential in the definition or analysis of alternatives 
and it was determined they do not impact development of the technical solutions based on 
these alternatives. 


Table 18: Levels of Interoperability 


NATOPS (A1-MQ8BA-NFM-000)/NATO Standard 4586 Edition 2 and 

AEP -57 Volume 1 

0 

All 

No air vehicle or payload actions allowed 

1 

Data 

Link 

Indirect receipt and transmission of payload 

data from another CUCS or C4 node via the 

Shipboard Modular Mission Package (MMP) 

2 

Payload 

Direct receipt of payload data from the AV 

3 

Payload 

LOI 2 + command and control of the payload 

4 

Vehicle 

Command and Control of an vehicle 

5 

Vehicle 

LOI 4 + Launch and Recovery of an vehicle 
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This assessment describes general technical impacts and approaches to 
implement the alternatives. This information is provided to characterize the integration 
and provide technical data relevant to the engineering feasibility and to articulate the 
level of engineering complexity for each alternative. Moreover, the technical approach 
described for each alternative was recognized as only one of many ways to achieve these 
capabilities. The purpose of the critical assessment is to identify a technical path 
forward, if the decision to pursue an alternative is taken. These approaches also facilitate 
evaluation of where the alternatives might enter the DOD acquisition framework. 

1. Alternative-1 (A-l) Analysis 

Alternative-1 for the MH-60 and Fire Scout interoperability consisted of LCS 
shipboard modifications. For this alternative, there was no direct interface between the 
MH-60 and Fire Scout. This alternative provided Level of Interoperability-1 (LOI-1) 
between the Fire Scout Shipboard Modular Mission Package (SMMP) and the LCS CIC. 
The focus was to give the LCS Tactical Watch Officer (TWO) in-flight oversight and 
near real-time access to Fire Scout Modular Mission Package (FMMP) payload data. 
Analysis of real time Fire Scout data is communicated to the MH-60 crew via voice 
communication. LOI-1 does not provide FMMP control to the LCS. SMMP assets are 
controlled by the LCS watch officer directing the SMMP Command Segment (CS) crew. 
The Fire Scout CS operating crew consisted of a Mission Commander (MC)/Air Vehicle 
Operator (AVO) and a Mission Payload Operator (MPO). 

a) Shipboard Controlling Node 

In this alternative the Fire Scout shipboard CS acted as the UAV controlling node 
and retained LOI-5 for takeoff, mission execution and landing, throughout all UAV 
sorties. The ship’s C2 received video and acted as a second non-control shipboard node. 
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b) TCDL Video File Format 


The Fire Scout NATOPS manual states the SMMP Tactical Control System 
(TCS) has the capability to publish National Imagery Transmission Format (NITF) 
imagery files (NTIF) data across Local Area Networks (LAN), and Tactical 
Communications Interface Modules (TCIM). Information about NITF data and its 
associated military standards can be found in Military Handbook 13 00A (MI1- 
HDBK1300A) 1 - 231 and in Military Standard 2500B (MIL-STD 2500B)'- 24 l Imagery in this 
format with supporting metadata will be transferred between the SMMP External 
Communication (EXCOMMS) equipment rack and the LCS Command, Control, 
Communication and Computer (C4) system. 


c) Shipboard Video File Transfer 

Shipboard LAN assets providing a conduit for video file information transfer and 
analysis will be necessary to determine if current shipboard network bandwidth supports 
video and data streaming throughput requirements. Figure 40 shows in red the video li nk 
between the Fire Scout SMMP and the LCS CIC. 
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d) General Work Required for A-l 


Additional analysis, follow-on engineering, and an evaluation of HSI 
requirements are requisite to developing any specific shipboard engineering proposals 
and estimate work required to modify, qualify and install hardware and software. 

Analysis of the existing LCS LAN is likely to reveal infrastructure upgrades 
necessary to meet throughput speeds necessary to stream certain video formats. These 
modifications would likely entail upgrading to faster network routers and switches. Also 
these upgrades may necessitate replacing existing cabling with newer higher bit-rate 
cabling for faster data rates. Additional upgrades to the LCS operator consoles are likely 
required to accommodate the new video source. These changes entail hardware 
enhancements for improved video buffering and switching. These hardware 
improvements will likely necessitate software modification to the LCS tactical C4 load in 
its video handling applications, 
e) A-l Conclusion 

From an engineering perspective, the integration of SMMP CS video with the 
LCS CIC consoles should be straight forward. The scored risk for the nine factors 
associated with A-1 is centrally located in the risk cube, presented in a subsequent section 
of this report. Only one factor (Lack of Shipboard Intel Manpower) is scored red and is 
non-engineering related, while the rest are scored moderate to low risk. Cost will be 
driven by work performed on the prototype and by shipyard availability. If A-1 is 
accomplished stand alone, the upgrade should be scheduled during construction or in an 
extended work period when the ship is pier side, while other moderate upgrades are being 
installed. Prototyping will aid risk reduction and confirm interface definitions and 
installation plans, and all data rights and licensing for software and design drawings will 
need to be addressed in advance. Once prototype integration is achieved and material 
procurement is complete, shipboard installation schedules can be addressed. 
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2. Alternative-2 (A-2) Analysis 


The focal point of Alternative-2 (A-2), shown in Figure 41, is on modifying the 
LCS and leveraging expected data link upgrades to the MH-60 helicopters. The Fire 
Scout equipment and operation are not effected in A-2. This option involves improving 
the existing MH-60 and LCS Link-16 tactical communication by providing the 
infrastructure necessary to fully utilize the follow-on H-60 Hawk Link capability. Hawk 
Li nk is a prospective CDL between the MH-60 helicopters and the LCS. Hawk link is 
currently being tested |26 ~ 22 and the higher data rate infrastructure is expected to facilitate 
MH-60 follow on TCDL upgrades on the MH-60 aircraft themselves and at receiving 
stations as well. The Hawk Link improvement facilitates increased capacity for the MH- 
60 to transmit data, thereby providing near-real- time sensor and video display 
information from MH-60 sensors to CDL and TCDL receiving stations. 

a) H-60 CDL-TCDL Hawk Link 

A-2 has no direct interface between the MH-60 and Fire Scout. Independent of 
the Hawk Link, the Fire Scout SMMP requires a TCDL antenna for communication 
between the LCS and UAV. CDL and TCDL data rates require dedicated Line of Sight 
(LOS) directional antennas. Upgrading the LCS communication arrays to include a 
second directional Ku Band TCDL antenna allows for reception of Hawk Link data. This 
provides a means for receiving MH-60 Multi-Spectral Targeting System (MTS) sensor 
data for display on the LCS operator consoles. By upgrading the LCS with second TCDL 
the LCS is given improved sensor data sharing capabilities, enhancing the tactical 
interaction process between the LCS C4 team and the MH-60 crew. 

b) LCS Tactical Watch Officer Review of both Fire Scout and MH-60 Video 

Although A-2 is an independent implementation, there is an expected synergistic 
increase in capability if both A-l and A-2 are implemented on the same platfonn. By 
providing LOI-1 interoperability between the SMMP and the LCS, and near real time 
MH-60 senor data to the LCS C4, it is anticipated the LCS will simultaneously display 
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MH-60 and Fire Scout senor data. This combined capability provides the LCS TWO the 
ability to compare data and potentially, to improve asset usage while reducing confusion 
when identifying contacts and prosecuting targets. 



Figure 41: Alternative-2 

c) Engineering for A-2 

A proposal to incorporate a second TCDL aboard LCS would require an analysis 
of alternatives to include engineering and an evaluation of HSI needs. An assessment of 
where to place the new antenna in the ship’s superstructure and its impact on ship stealth 
would be necessary. A-2 is essentially a communication suite upgrade requiring a 
comprehensive review of the operator console for the new source of video and sensor 
data. Although these upgrades seem similar in scope and capability to the improvements 
associated with A-1 they are from a different source and need an independent assessment 
of the requirements. 


i. TCDL Data Transfer and Protocols 


Since TCDL data transfer is based on Ethernet protocols, an analysis of the 
existing LCS LAN for A-2 may also reveal infrastructure upgrades are required for 
throughput requirements. 
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ii. LCS Hardware Upgrade 


Upgrades to LCS operator consoles are likely. As stated above, it cannot be 
assumed an upgrade made to meet A-1 need will be robust enough to carry A-2 data or 
especially a combination of both A-l and A-2. These changes entail hardware 
enhancements for improved video buffering and switching. Software modifications to the 
LCS tactical C4 load are likely needed to improve processing for applications associated 
with handling video. 

iii. Fire Scout Control 

Fire Scout is autonomous within A-2 so the Fire Scout SMMP will retain full 
LOI-5 control of the UAV throughout any combined sortie. 

d) A-2 Conclusion 

Like A-l, upgrading the existing LCS communication suite to include a second 
TCDL is expected to be straight forward. The risk factors associated with A-2 are 
centrally located in the risk cube for this alternative, provided later in this report. As with 
A-l a lack of ship’s force Intelligence manpower was the only factor scored as a high 
risk, while the rest are scored moderate to low risk. This is a non-engineering associated 
risk factor and has no impact on developing a technical solution for A-2. Analysis of the 
impact of adding the TCDL to the LCS RADAR profile would require a certain amount 
of operational test range time. The cost of LCS RADAR profile testing would need to be 
added to any comprehensive cost estimate for A-2. As with A-l cost is expected to be 
driven by work performed on the prototype and by shipyard availability. If A-2 is 
accomplished stand alone, effort should be made to align maintenance schedules when 
the ship is pier side. The effort to modify LCS inboard infrastructure is expected to be 
comparable to the engineering effort required to bring the Fire Scout SMMP data into the 
LCS CIC consoles. 
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3. Alternative-3 (A-3) Analysis 


The Alternative-3 (A-3) is the most challenging option to develop and involves 
modifications to both aircraft. A-3 involves incorporating TCDL data cross links 
between the Fire Scout and MH-60. This encompasses incorporating two TCDL 
equipment packages aboard both the Fire Scout and MH-60, or expanding the current 
capabilities of the Fire Scout TCDL and MH-60 Hawk Link to meet the additional work 
load. In either case, a second LOS directional TCDL antenna is required to be installed 
on both aircraft. Thought should be given and analysis perfonned to determine if 
additional airborne interoperability is fully utilized without modifications to the LCS 
ability to receive, process and transmit data accordingly. In A-3 the MH-60 helicopter 
receives FMMP payload and control data directly from the Fire Scout. A-3 currently has 
two variants and an analysis of alternatives to down select between LOI-2 and LOI-3, or 
to determine the synergistic benefits of implementing both LOI-2 and LOI-3 
modifications should be conducted. Figure 42 presents A-3 communications paths. 


Option/Spiral 3A 

H-60 & UAV 
Shared data-link only 


Option/Spiral 3B 

H-60 & UAV 
Shared data-link plus 
H-60 Control of UAV 
via data-link 



Figure 42: Alternative-3 
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a) COTS Alternative and UAV Control Options 


A-3 moves the Primary Data Link (PDL) from the LCS SMMP and establishes 
TCDL control on the MH-60. An analysis of alternative equipment needs to take place, 
but small Commercial Off The Shelf (COTS) TCDLs such as the L3 Corporation Multi- 
Role Tactical Common Data Link (MR-TCDL) I 26 ! or the L3 Corporation Mini TCDLl 27 ! 
indicate technically mature products are available. These COTS equipment packages 
are already sized to fit aboard both the MH-60 and the Fire Scout. Although suitable 
products may be available, factors such as size, weight, and HSI concerns can be more 
challenging for aircraft integration than for shipboard applications. Additional evaluation 
of the suitability of these devices should be conducted. 

b) Fire Scout Control during Launch and Recovery 

It is expected that for A-3, the present configuration of the SMMP with redundant 
UHF/VHF Secondary Data Links (SDL) will be retained aboard LCS for use during 
UAV launch and recovery. The Fire Scout MC/AVO will remain aboard LCS and from 
the SMMP is expected to retain master control and continuous LOI-5 during UAV launch 
and recovery due to safety concerns. From the SMMP, the MC/AVO is likely to 
maintain responsibility for monitoring UAV point-of-safe-retum and UAV general stores. 
Hand shake operation between the MH-60 TCDL and SMMP TCDL will move LOI-2 or 
LOI-3 control from the SMMP to the MH-60 TCDL during the ingress, on-station, and 
egress, phases of the Fire Scout flight plan. 

c) Antenna Usage in A-3 

Combinations of omni-directional and directional antennas on the LCS, Fire 
Scout and MH-60 provide a mix of data signal reception ranges. Continuous UHF/VHF 
SDL between the LCS and UAV is only necessary for launch and recovery operation. 
Within A-3 Loss of Communication (LOC) procedures and automatic functions may also 
shift to the MH-60 data li nk . 
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d) Link-16 Tactical Data Management Retained 


Both the H-60 NATOPS (A1-H60RA-NFM-000) and NATIP (NTRP 3-22.4- 
MH60R) discuss the current communication suite aboard the MH-60R Helicopter. Link- 
16 presently provides Tactical Data Management (TDM) for presenting a Geographical 
Situation (GEOSIT) display using its Data Fusion (DF) capability to De-clutter (DCLT) 
contact and target tracks. Additionally Link-16 supplies avionics interface control and 
ESM system interface through its Avionics Operating Program (AOP). Due to space and 
weight constrains Link-16 TDM and onboard avionics interface and control is anticipated 
to merge into the Hawk Link system. Timing and integration should be coordinated 
between A-3 and Hawk Link projects for efficiency. The first order of analysis should be 
to determining the feasibility of using a single link solution, to include link control and 
loading characterization. 

e) UAV TCDL Sensor Payload Management Merged with Hawk Link 

Adding UAV sensor payload management to the existing Hawk Link capabilities 
is the principal challenge for A-3. Merging and augmenting the present MH-60 controls 
and indicators are both an engineering and HSI challenge. 

f) Required Fire Scout Modifications 

A-3 requires modifications to Fire Scout including adding hardware sustaining a 
second LOS antenna and software changes to provide seamless LOI-2 and LOI-3 
switching between the SMMP and the MH-60 TCDL terminal. Other UAV software 
adaptations may be moderate since all capabilities are already developed and switching 
the application control source is the singular development focus. UAV hardware 
upgrades would is limited to stepping up the existing UAV TCDL receivers to interface 
with a second LOS antenna and installing the antenna. 
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g) Required MH-60 Modifications 


A-3 modifications to the MH-60 may be extensive. The upgrades may include 
major software changes, including integration of UAV TCDL data control capabilities. 
The MH-60 crew station and HIS may be impacted, especially the control and display of 
information at the crew operating consoles. Providing an integrated tactically efficient 
MH-60 Hawk Link and Fire Scout TCDL operating interface will require extensive 
engineering analysis to specify impacts to the airframe, as well as mission systems. For 
example, a second LOS antenna and its supporting components may be essential. 

h) A-3 Conclusion 

A-3 is an independent development and does not need to be associated with A-1 
or A-2. A-3 provides the greatest asset interaction by providing high bandwidth data 
directly between aircraft, potentially reducing delay and error. As with the earlier 
options, A-3 has the same high risk factor for lack of ship’s force Intelligence 
manpower. Although the implementation has more pervasive and complex impacts to the 
existing systems, the majority of the scored risks were either moderate or low. The 
external modifications to Fire Scout are limited to adding another TCDL LOS antenna. 
Internal modifications are expected to be limited to software changes. External changes 
to the MH-60 are also limited, adding a second TCDL LOS antenna, but internal 
modifications are expected to be extensive. The degree of change may require regression 
testing and requalification of subsystems and system integration and flight test. Cost 
estimation for A-3 will encompass the full range of factors included in building or 
performing major modification to an aircraft based on an event driven development 
schedule, to include risk reduction prototyping. Because different contractors would be 
involved, licensing and data rights should be resolved early in the project timeline. 

High bandwidth data transfer between aircraft affords tactical flexibility and 
improves asset usage by allowing the MH-60 aircrew direct access to Fire Scout payload 
data and control of onboard sensor. Although A-3 can be developed as a standalone 
implementation, as with previous alternatives, combining solutions may offer the greatest 
potential increase in the overall system effectiveness. 
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C. COST ANALYSIS OF ALTERNATIVES 

The cost analysis was based on a high-level Work Breakdown Structure (WBS) 
that was created for each alternative. Table 19 provides a sample WBS. The WBS 
estimates were developed using market research associated with the cost of similar 
modifications on MH-60 variants. Subject matter experts provided the estimates for each 
element of the WBS based on experience with similar modifications on MH-60 and other 
platforms. The team relied on experienced personnel from PMA-299 who have managed 
and perfonned aircraft modifications to rotary wing platforms and other systems for the 
past 20 years to provide data relevant to these efforts. The subject matter experts 
provided a point estimate for each alternative that was based on the sum of all of the 
single best-cost estimates for each WBS element. Because there was not a large 
comparable database of cost information for similar system modifications, the decision 
was made to use a point estimate method supported by engineering judgment. It should 
be noted that a point estimate is a very precise, yet often inaccurate cost model. 


Table 19: Alternative 1 WBS Excerpt 


WBS 

Description 

Cost 

1.0 

Non Recurring Engineering 


1.1 

Definition of requirement for TCDL data transmission 

$25,000 

1.2 

Definition of requirement for display of TCDL data on C2 console 

$25,000 

1.3 

Analysis of existing LCS databus hardware architecture 

$25,000 

1.4 

Architecture modification to shipboard data bus hardware 

$25,000 

1.5 

Analysis of existing LCS databus software architecture 

$25,000 

1.6 

Architecture modifications to shipboard data bus software 

$25,000 

1.7 

Analysis of Alternatives 

$20,000 

1.8 

Alternative Selection 

$5,000 

1.9 

Integration Design 


1.9.1 

Prototyping Hardware 

$25,000 

1.9.2 

Prototyping Software 

$40,000 


The WBS was used to accumulate costs for the materiel and work necessary to 
implement each alternative. Following the point estimate method, the total cost for each 
alternative was calculated as a roll-up value. The cost estimate for each alternative is 
shown in Table . 

Table 20: Cost Estimate for Each Alternative 
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Cost 

Alternative 1 

$2,016,000.00 

Alternative 2 

$2,571,000.00 

Alternative 3 

$3,696,000.00 


Ideally, the cost estimate would be determined using a cost estimating relationship 
(CER). The CER is based on distributions of input data, including average unit cost, 
production quantity, fiscal year, and possibly weight or other dimensional data. This cost 
data would be nonnalized to any given fiscal year dollars using a cost inflation index. 
Different cost estimating theories can be applied to adjust the average unit cost by 
considering a learning curve and to determine the Theoretical First Unit cost. The dataset 
of Theoretical First Unit cost and weight or other dimensional data is used to create 
different CER’s. The CER which provides the lowest Percent Error and the highest 
correlation would be the equation used to predict the Theoretical First Unit cost and total 
production cost of the new modification. Monte Carlo simulations would be run to 
provide a distribution of estimates with a quantified risk. This distribution of estimates 
would be used to justify the budget for the modification program. 

A more thorough cost analysis is recommended in the follow on work to 
minimize risk due to cost uncertainty. The estimate does provide a framework for use in 
refining cost estimates in the future. 

Despite the limitations in method and available data, an important aspect of the 
project was to provide a framework for recommending an SOS alternative solution that 
was both operationally effective and programmatically achievable. To this end, the cost 
estimate was perfonned to complement the Utility Scoring assessment, building on the 
M&S research and analysis, in order to provide a “Bang for the Buck” recommendation. 

It was expected that the relative ranking of cost versus capability for the SOS alternatives 
would be useful information to stakeholder deliberations. The “Bang for the Buck” 
plots of cost versus utility are presented in Figure 43. 

The plots indicated that Alternative 1 achieved the lowest cost and highest utility. 
This outcome confirms expectations and is consistent with the results of the project 
research, specifically, the Excel-based model results and to a limited extent, the NSS 
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finding that Alternatives 1 and 2 provided overall the most improvement in mission 
effectiveness as a direct result of improved data-level interoperability within the SOS. 
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Figure 43: Cost versus Utility Plots 


D. RISK ASSESSMENT 

The risk assessment was performed to aid stakeholder decision-making, as well as 
to complement the Critical Assessment of the implementation impacts provided in the 
preceding section of this report. A risk assessment was conducted on each design 
alternative to include: identification of risk areas, analysis to determine the likelihood 
and consequence associated with each risk (a quantitative measure), and preliminary 
mitigation planning. Risk management should begin at the earliest stages of program 
planning, continue throughout the total life cycle of the program, and was an important 
factor in defining the alternative configuration and subsequently, in determining the best 
value system design during the Analysis of Alternatives. For this interoperability 
project, the impact of software development and integration efforts was addressed as 
part of the program’s risk management activities. Preliminary areas of risk were 
identified for this project as part of the initial project planning. These initial areas are 
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discussed in this section and refined throughout the project. These risks also provide a 
basis for further assessment in follow-on efforts. As the project progressed, newer more 
accurate risks were also identified. These are also discussed in this section. 

1. Initial Risk Areas 

Initially top-level, programmatic risks where identified. These risks are shown on 
a risk-cube in the following Figure 44 and listed below with numbers corresponding to 
those in the risk cube. This identification process was preliminary and provided a guide 
that the project team could use to steer the project for risk mitigation purposes. These 
risks were mostly technical in nature. It is helpful to keep in mind that these risks have 
been superseded by newer, more accurate risks. However, discussion of these risks is 
useful and will provide a history of risk identification in this project. 
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Figure 44: Initial Risk Profile 



2. Listing of Initial Risks 
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1. System Level Requirements Definition 

2. Identification of Testable Measures of Effectiveness 

3. Bus Loading/Data Link Bandwidth to Accommodate Additional ISR Data 

4. Mission Computer Processing Capacity 

5. Fidelity of Modeling and Simulation 

6. Software Modifications Required to Update Operator Displays and Integrate Data 

into Mission Computing Systems 

a) Programmatic Risks 

The initial programmatic risks are listed below. These risks were identified as 
items that could potentially hinder the actual systems engineering effort and not 
necessarily the technical design aspect of the project. 

• System Level Requirements Definition 

• Identification of Testable Measures of Effectiveness 

• Fidelity of Modeling and Simulation 

There was discussion as to whether identification of requirements could pose a 
problem. Identification of true stakeholders was a concern mainly because of the 
academic nature of this project. Without an actual JCIDS document, it was thought that 
gathering realistic requirements would be an issue. These risks did not materialize due to 
the fact that there was strong interest in this project from stakeholders, who provided 
valuable input. 

Because actual testing was not an option for this project, the team found it 
difficult to confirm that MOEs proved testable. The simulation of the project’s mission 
scenario handled the testing aspect of this project. This simulation was a proof of concept 
and pseudo-test event. Over time, the team was able to identify an MOE that could be 
proven through simulation and the risk was mitigated. 

The final programmatic risk was based on the concern that the simulation of the 
project’s mission scenario would not possess enough fidelity to provide an accurate and 
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stable result and conclusion. This risk has been present throughout the project and has 
impacted the final results to some degree, with explanation where practical. 

b) Technical Risks 

The initial technical risks are listed below. These risks were identified as potential 
issues that could affect the technical design being suggested. 

• Bus Loading/Data Link Bandwidth to accommodate additional ISR data 

• Mission Computer Processing Capacity 

• Software Modifications required to update Operator Displays and Integrate data 

into Mission Computing Systems 

Because the project was handling the addition of new sensor data to a pre-existing 
bus the risk of bus overload came to mind. Actual bus utilization needed to be assessed, 
once sufficient traffic characterization could be defined, as well as the bandwidth 
required by the new sensor data. 

Much like the bus-loading risk, a risk was identified that could affect the mission 
computer. Because the mission computer is pre-existing it has a pre-detennined 
processing capacity. This capacity was unknown, as was the capacity required to handle 
the new mission requirements. 

A risk was identified for the integration of the Fire Scout operator displays and 
the mission computing systems aboard the LCS and MH-60. This risk focused on the 
potential for modifications to these systems to make them interoperable. The risk existed 
because the nature of these modifications was unknown and therefore, feasibility is also 
unknown. 

Identification of risks within each alternative showed that certain risks were 
isolated to one alternative while other risks were present in two or three of the 
alternatives. The discussion in this section of the report will focus on individual risks 
while pointing out which alternatives are affected. A summary of each alternative will 
also be provided. 
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2. Refined Risk Areas 


Once a clear vision was established and requirements took shape, more specific 
risks were identified. These risks were more accurate and painted a clearer risk picture 
through the lens of the systems engineering alternatives. Risks were addressed and 
discussed individually for the alternatives where they apply. 

a) Lack of Shipboard Intel Manpower 

• Alternatives Affected: 1, 2, & 3 

• Consequence & Likelihood: (4,4) 

• Level: High 

• Type: Operational Suitability 

This risk deals with requirements levied on the LCS crew to support the additional 
functionality proposed by this project. It is unknown whether there is enough manpower 
to handle the additional sensor data and process it in a timely manner. Especially 
challenging is the need to provide intelligence specialist manpower to exploit imagery in 
support of decision-making. This specialty area is in high demand for Naval and Joint 
operations and may not be available for LCS deployment. Mitigation efforts could come 
in the form of a manpower study and further recommendation on what resourcing 
modifications may be needed, if any. 

b) Support for Shipboard Aviation Mission Solution 

• Alternatives Affected: 1 & 2 

• Consequence & Likelihood: (3,4) 

• Level: Moderate 

• Type: Schedule 

A risk to implementation exists because the LCS is not currently tasked with 

supporting a full aviation mission. The success of what this project proposed was 

based on many individuals and groups within the Navy and DOD agreeing to an 
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unmanned paradigm shift. Mitigation for this risk was to provide an accurate study 
and assessment to the risk/reward aspect of proceeding down this path. This project 
takes a first steps in doing so. 

c) Fire Scout Control Station and LCS CIC Interface Incompatibility 

• Alternatives Affected: 1 & 2 

• Consequence & Likelihood: (4,3) 

• Level: Moderate 

• Type: Performance 

A portion of the technical solution deals with data sharing between the Fire Scout 
CS and the LCS CIC. A risk exists because there is currently no interoperability 
between these two systems. Mitigation could come in the form of performing 
analysis on the interfaces these two systems possess and proposing a solution to 
provide interoperability. 

d) Software Modification required to Support Fire Scout video at LCS CIC 

• Alternatives Affected: 1 & 2 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Performance, Schedule 

This risk goes hand-in-hand with the previously discussed risk. Once an interface 
solution between the Fire Scout CS and LCS CIC is defined, the LCS CIC will be 
required to display and manipulate Fire Scout sensor data. The software modification 
effort to implement this is unknown. Mitigation, like the previously discussed risk, 
would be system analysis with software change impacts to determine a possible 
solution to achieve the desired results. 

e) Ship Availability for Modification Install 

• Alternatives Affected: 1 & 2 
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• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Schedule 

A risk exists because the LCS would need to be taken away from duty to 
implement the proposed modification. Schedule factors may affect the modification. 
Mitigation for this risk is to provide the most accurate schedule for the LCS 
availability with the greatest amount of lead-time possible. 

f) Impact to Software baselines by New Software Modifications 

• Alternatives Affected: 1, 2, & 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Performance, Cost 

Each system that requires a software modification already possesses a software 
baseline with critical mission functionality. It is common that modifications to an 
existing software system result in unintended consequences, sometimes in the form of 
disruption to the software baseline. This risk exists for this project because systems 
related to the LCS, MH-60, and Fire Scout may require software modification. 
Mitigation for this risk comes in the form of rigorous software quality standards and 
extensive testing. 

g) LCS Console Operator Workload 

• Alternatives Affected: 1 

• Consequence & Likelihood: (2,3) 

• Level: Low 

• Type: Operational Suitability 

Additional mission functionality will lead to additional work-loading of those 
aboard the LCS, specifically, the operator of the LCS’s console. Current workload 
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needs to be gathered and assessed with the potential additional workload proposed by 
this project. A human factors analysis should be perfonned to detennine if additional 
manning is required for mitigation purposes. 

h) Potential Inaccuracy of NSS Model Due to “Cumulative Alternatives” 

• Alternatives Affected: 1, 2, & 3 

• Consequence & Likelihood: (3,2) 

• Level: Low 

• Type: Performance 

This risk is related to the potential inaccuracies associated with modeling the 
mission scenario. Because various alternatives can consist of cumulative functional 
build-ups and the modeling approach was not cumulative, additional manipulation is 
required to provide an assessment of the cumulative effects of incorporating multiple 
alternatives. The risk is that of an inaccurate result due to the model not being specific 
for the mission scenario. Mitigation for this risk can come in the form of additional 
modeling and analysis. 

i) LCS Ability to Accommodate Additional Antennas 

• Alternatives Affected: 2 

• Consequence & Likelihood: (4,3) 

• Level: Moderate 

• Type: Performance, Cost 

There is a risk of incorporating an additional antenna aboard the LCS to 
accommodate the simultaneous of the Fire Scout and MH-60 data li nk s to the 
LCS. Locating a suitable integration for the antenna and supporting equipment is 
required to mitigate this risk. 

j) Infrastructure to Support Additional TCDL 

• Alternatives Affected: 2 
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• Consequence & Likelihood: (3,2) 

• Level: Moderate 

• Type: Performance, Cost 

This risk is closely related to the previous antenna risk. Because the LCS 
will need to be able to communicate with the Fire Scout and MH-60 
simultaneously an additional TCDL channel is required. It is unknown if the 
infrastructure to support this exists or if modifications to the LCS will be required. 
An engineering analysis is needed to better clarify the nature of this risk as well as 
identify what may be required to implement an additional TCDL. 

k) Aircraft Weight Additions 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Performance 

With most physical upgrades comes additional equipment. This usually 
leads to additional mass and weight requirements. Weight is a critical factor in the 
aviation world. This risk exists because there is the potential for weight additions 
to the MH-60 and Fire Scout. These weight additions could lead to u nkn own 
mission impacts that restrict operations. This risk can be mitigated by treating 
weight as a KPP during the system design process or incentivizing the integrator 
or contractor to minimize weight growth by design. 

l) Video Communication between Fire Scout and H-60 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Cost, Schedule, Performance, Operational Suitability 
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A new communications channel is required between the MH-60 and Fire 
Scout to view the Fire Scout sensor data. The nature of this implementation is 
undefined and an engineering study into potential solutions is needed to mitigate 
this risk. 

m) Disorientation and Motion Sickness when Viewing Sensor Data Aboard MH-60 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Operational Suitability 

Preliminary analysis yielded a risk to operational suitability due to a 
human factors concern. It is known that viewing video aboard one aircraft in 
flight from another aircraft’s in-flight perspective can lead to motion sic kn ess and 
thus degraded or null capacity to perform the mission. Additional human factors 
analysis is required in this area to clarify the details of this risk and present 
potential guidelines to reduce this potential effect before Fire Scout video aboard 
the MH-60 is implemented 

n) Integration Complexity 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Cost, Schedule, Performance 

There are a variety of ways to incorporate the functionality associated with 
each of the alternatives. For Alternative 1, the requirement is to implement a 
communication channel between the FSCS and the CIC on the LCS, in order to 
share Fire Scout sensor data. This communication channel could take the form of 
an Ethernet link, Optical Fibre channel, hardwired RS-170 video line, etc. 
Alternative 2 requires integration of an additional TCDL Data Link channel on 
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the LCS to support reception of data from both the Fire Scout and MH-60 
simultaneously. For one configuration of the LCS ship, two channels of TCDL 
and two antennas are already integrated, but the second independent channel is 
not enabled. On the other LCS configuration, there is only one TCDL antenna, 
necessitating integration of a second antenna. With two antennas and two aircraft 
operating TCDL simultaneously, there is the possibility of blockage of one of the 
antennas by ships structure, effectively blanking the video from one of the 
aircraft. Optimally, each TCDL channel would have full 360 degree coverage, 
which would necessitate multiple antennas and antenna switching. Alternative 3 
requires the MH-60 to receive sensor data from the Fire Scout and also, to take 
control of the sensor. Integration of a communication channel for receipt of the 
sensor data could take a variety of forms and could impact both the MH-60 and 
Fire Scout. Taking control of the Fire Scout sensor would require integration of a 
communication system and control station on the MH-60, and would also require 
control negotiation between the MH-60 and the LCS-based Fire Scout control 
station. Complexity translates to risk. 


The selection of this approach will drive the integration complexity, and 
thus drive Cost, Schedule, and Performance. The analysis of alternatives and 
selection of a recommended approach is left for follow-on work. 

o) Data Latency Across Platforms 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,3) 

• Level: Moderate 

• Type: Performance 

Complex communications systems consisting of data links can be plagued by data 
latency, especially with the implementation of multiple data links leading to 
compounded latency issues. Latency is a risk to the implementation of 
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interoperability between the Fire Scout and MF1-60 platfonns. Communication 
system tests are required to account for potential mission data flows and bandwidth. 
Perfonning tests of this nature will help shed light on the details associated with this 
risk. 

p) Increased Range 

• Alternatives Affected: 3 

• Consequence & Likelihood: (2,3) 

• Level: Low 

• Type: Performance 

Increased range is a possibility with the implementation of additional data links. 
Although this increased range may seem useful, increased operational time, fuel 
stores, and decreased MTBF are all possible impacts that may counter the benefit. 

q) Data link Robustness 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,2) 

• Level: Low 

• Type: Performance 

Where specific system functionality relies on the robustness of the data link for 
capacity, latency or other transmission attributes, there is risk to performance. 
Potential problems include susceptibility to jamming and/or the potential for a non¬ 
lock situation where the data link cannot initialize causing mission ineffectiveness. 
Analysis of the potential operating environment and potential link employment are 
required to mitigate this risk. 

r) Fire Scout Hand-off Command to MH-60 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,2) 
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• Level: Low 


• Type: Performance 

This risk is addressed above as part of Section n). 

s) Non-Availability of Frequency Spectrum for Operations 

• Alternatives Affected: 3 

• Consequence & Likelihood: (3,2) 

• Level: Low 

• Type: Performance 

When implementing new data links with additional bandwidth requirements it 
is important to locate a suitable portion of the RF spectrum in which to operate. 
The new communications requirements proposed by this project will lead to 
additional RF spectrum needs. Analysis is needed to determine impacts and 
detailed requirements. 

3. Alternative Risk Profiles 

The previous portion of this section of the report detailed each individually identified 
risk. These various risks affect one or more different alternatives for this project. This 
section lays out the risk profile per alternative. The risk profiles are presented in Figure 
45, Figure 46 and Figure 47. The letters in the risk cubes refer to the risks outlined in the 
previous section. 

b) Alternative 1 Risk Profile 

Alternative 1 deals with the interconnection between the Fire Scout CS and the LCS 
CIC, so many of the risks dealt with this integration, but also addressed the need for 
additional manning resources, system upgrades, software modification, and availability of 
the LCS for upgrade and modification. Figure 45 shows the risk profile for Alternative 1. 
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Figure 44: Alternative 1 Risk Profile 

c) Alternative 2 Risk Profile 

Alternative 2 handles the functional upgrade to provide simultaneous 
communications li nk s from the LCS to the MH-60 and the LCS to the Fire Scout. The 
risk profile for Alternative 2 addresses many of the same risks as for Alternative 1, but 
also focuses on the physical changes required to support this functionality. Figure 46 
presents the risk profile for Alternative 2. 
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Figure 46: Alternative 2 Risk Profile 




149 


























d) Alternative 3 Risk Profile 


The risk profile for Alternative 3 is differentiated from the risk profiles of 
Alternative 1 and 2 because by emphasis on aircraft modification. Although Alternative 3 
shares some risks with the other alternatives it addresses many more concerns that come 
with adding functionality to the air platforms and their communication systems. Figure 
47 shows the risk profile for Alternative 3. 
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Figure 47: Alternative 3 Risk Profile 

VI. CONCLUSIONS AND RECOMMENDATIONS 

The goal of this research was to perfonn the Systems Engineering analysis 
required to determine whether an integrated SOS of MH-60, Fire Scout and LCS, 
working on a shared COTP with enhanced data communications achieves a more 
effective solution defending the LCS or other HVA against SWARM threats. The result 
was the development of a foundation, framework, architecture, and analysis of 
alternatives required to formulate a recommendation for an SOS alternative The table 
below provides an overview of the results, which is described in greater detail in 
following paragraphs. The data below shows the comparative rank between the 3 
alternatives. 
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Alternative 

Effectiveness 

Cost 

Risk 

1. Fire Scout Control 

Station to CIC link 

1 

1 

1 

2. 2 nd TCDL Channel 

3 

2 

2 

3. Sensor and Control Link 

between Fire Scout and 

MH-60 

2 

3 

3 


The research determined three separate opportunities existed to improve the 
decision-making time. These opportunities were subsequently defined as SOS 
alternatives. First, the Fire Scout sensor data (video) was data-linked to the Fire Scout 
CS on the LCS. The FSCS was not connected to the CIC on the LCS, so there was no 
convenient way to get the Fire Scout sensor data to the decision makers in CIC. 
Alternative 1 addressed improvements to the LCS to accommodate electronic passage 
and distribution of data within the LCS, providing “more” and “faster” data to the 
decision makers. 

Another limiting factor in the communication chain was that there was only one 
TCLD channel in use on LCS, even though there were two channels available. The MH- 
60R helicopter had a Hawk Link that is compatible with the standard CDL message 
structure, whereas the Fire Scout was equipped with TCDL, based on the standard CDL. 
Currently, only one aircraft can send sensor data to the LCS down the TCDL data link. 
(Further, only one of the LCS ship configurations has two data link antennas. The other 
has only one antenna, and thus is only capable of a half-duplex link between the two 
aircraft.) Given the opportunity to employ existing data links, Alternative 2 addressed 
opening up both TCDL channels so that sensor data from both aircraft can be monitored 
simultaneously. Opening up both TCDL channels on the LCS again provided “more” 
and “faster” data to the decision makers. Also, since the MH-60R is currently the only 
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MH-60 in the inventory with a CDL-compatible data link and is planned to deploy from 
the LCS, it became a focal point for our analyses. 

The third and final alternative investigated was to provide Fire Scout sensor data 
to the MH-60 helicopter to support sensor fusion, and to provide control of the Fire Scout 
sensor system by the MH-60. This approach would allow the MH-60 the capability to 
merge Fire Scout sensor data with on-aircraft data, and provide a more complete picture 
for making tactical decisions. This approach would require integration of the Fire Scout 
and MH-60 via data li nk s. Potential implementation, for example may entail TCDL data 
link onboard the MH-60R to accommodate reception of the Fire Scout sensor data, re¬ 
transmission of that data to the LCS, or fusion of the Fire Scout data with MH-60R data 
for transmission to the LCS. It would also necessitate installation of FSCS components 
and applications on the MH-60R for control of the sensor suite. This approach provided 
“more”, “better”, and “faster” data to the decision makers, and also allowed the Fire 
Scout and MH-60 to work together when prosecuting a threat by using cooperative 
tactics. 

The project employed both an Excel model and the Naval Simulation System 
(NSS) model to simulate the aforementioned alternatives, using time estimates for the 
steps in the decision chain. The SOS baseline performance was modeled first for 
comparison with each of the three alternatives. The Excel model indicated that 
Alternative 3 would provide the greatest improvement on the key metric, “Time to 
Identify.” Interestingly, the NSS model did not yield the same results. The differences in 
outcomes was analyzed and led to the conclusion that the NSS model was not created 
with the necessary fidelity to accurately capture the parameters of the mission scenario. 
The finding that warfare analysis models must be purpose-built for systems engineering 
analysis, by carefully defining the format and content of input and output parameters for 
the systems, scenarios and architectures, is an important lesson learned for the systems 
engineering process and further research. With additional time (and funding), the NSS 
model could be modified to better reflect the system engineering concerns and yield more 
informative and practical results. For example, the NSS model should be redesigned to 
support combining the effects of implementing more than one alternative. 
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To ensure the research and analysis of alternatives activities support stakeholder 
interests and future program decision-making, the project created a Work Breakdown 
Structure and defined the tasks required to implement each of the alternatives as a stand¬ 
alone effort. A parametric cost estimates was performed to create a “bang for the buck” 
assessment of the alternative. A high-level risk assessment was performed to categorize 
and quantify risks associated with each alternative. Collectively, the research addressed 
effectiveness of alternatives and provided a framework for assessment of cost, risk and 
performance impacts. 

The project concluded that Alternative 1, linking the FSCS and CIC directly via 
data link onboard the LCS would provide the best “bang for the buck” to improve overall 
mission effectiveness through improved interoperability. This alternative was the least 
complex compared to the others, in tenns of physical and functional integration. It was 
also, therefore, brought the least risk and cost to a solution for the original requirements. 

Within the limits of the modeling assumptions and mechanics, the NSS model 
results indicated that Alternative 2, enabling the second TCDL channel on the LCS ship, 
would provide the greatest effectiveness. Taken together, the research outcomes provide 
an important systems engineering insight that indicates an additive, incremental approach 
for implementing the three leading alternatives may be feasible and the optimal way to 
meet the requirements while evolving manning concepts, tactics and training for SOS 
operations between manned and unmanned assets. Each alternative could be pursued 
separately, but the combination of Alternative 1 and 2 may address not only the mission 
in focus, LCS defense against a swarm of small boats, but also provide a robust solution 
for improved interoperability and effectiveness across multiple missions. Modeling and 
analysis of cumulative effects may confirm that it would be more beneficial to implement 
Alternative 1 prior to or in conjunction with Alternative 2, as opposed to only Alternative 
2. The same is true for the combined effects associated with Alternatives 1 and 3. 
Alternative 3 presented the highest cost and technical risk, but could also ultimately 
achieve the greatest interoperability improvement as mission planning methods and 
tactics are developed. Currently, there is very little operational experience with the Fire 
Scout operating from a small ship such as the LCS, but as more experience is gained, 
greater utilization of the Fire Scout capabilities as a stand-alone aircraft, and eventually 
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as an interoperable asset, will be achieved. This will open the doors for development of 
new missions and tactics. The foundation that has been laid by this research supports 
development of these future capabilities. 

B. FINDINGS SUMMARY 

As previously indicated, several issues associated with the NS S model impacted 
confidence in the results of the analysis of alternatives. Below are several areas where 
the model could be changed to provide more information results supporting the SE 
approach. 

• The tactical situation chosen for analysis addressed a small boat swarm attack in a 
choke point, such as the Straits of Hormuz. The NSS model, while showing the 
landmasses in its output presentation, actually simulated the scenario as if it was 
an open-ocean, blue-water scenario. This is a limitation of the way the model was 
constructed, and came about as a result of using parts of a previously developed 
model. This yielded a less realistic geometry for the location and distribution of 
targets. 

• The model did not address the historical retention of targets once they had been 
“visited” by either the MH-60 or the Fire Scout. This allowed, and in some cases 
necessitated, multiple visits during the simulation run, which extended the 
scenario time. 

• The model did not take into account either the geometry of the target layout, or a 
prioritization of targets other than “which one is closest to the HVA”. This led to 
significant “traverse time” where one air vehicle was criss-crossing over the HVA 
to go from one near-target to another, as opposed to designing in the assignment 
of a region of interest for each air vehicle to address. Additionally, the NSS 
model did not account for the use of a search pattern, such as a ladder search, 
which could optimize the effectiveness of the air vehicle when finding targets. 

• The model was not designed to support the cumulative effects associated with the 
employment of both Alternatives 1 and 2, or 1, 2, and 3 in combination. To 
realize the full potential benefit of Alternative 2 (dual TCDL channels), 
Alternative 1 (communication link between the FSCS and CIC) may also be 
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required. By combining these alternatives, even greater interoperability 
improvements may be achieved than by incorporating either alternative as a 
stand-alone effort. 

It is for the aforementioned reasons that the results of the NSS model simulation came 
into question during the analysis of alternatives. The results did not correlate with the 
“back of the envelope” calculations run in Excel, and did not make logical sense when 
the Time To Identify MOE actually increased even though more channels of 
communication were opened to support faster decision making. Below are listed 
additional changes that could be made to the model to make it more realistic in the given 
scenario. 

• Account for AIS data from benign shipping vessels. The AIS system was 
mandated for shipping vessels greater than 300 metric tons, and provides data 
such as ship name, country and port of origin, location, speed, direction, cargo, 
etc. The Fire Scout has an AIS receiver system integrated into its sensor suite, 
which would allow the CS to coordinate with CIC to detennine which of the 
targets could be ignored in a high-intensity situation. 

• Account for RADAR return data, such as ship size, to eliminate candidate targets 
from consideration. The LCS, Fire Scout, and MH-60R all have advanced 
RADAR systems that can account for the size of a ship, and in SAR mode, could 
even generate a detailed scan of the structure allowing profile identification. This 
factor was not taken into account in the model, but surely would be during a real- 
world situation, again minimizing the number of targets to be prosecuted. 

• When the model was programmed, 65 targets were input, 25 of which were 
potential threats, the remaining 40 being commercial vessels ranging in size from 
pleasure craft to commercial fishing to container and large shipping vessels. Had 
the available sensor data (RADAR and AIS) been used as a discriminator, the 
target population may have been significantly reduced to threats more quickly. 
Had this data been used to formulate a coordinated prosecution plan within the 
model, using target characteristics such as proximity, speed, size, etc., a more 
realistic and coordinated investigative approach could have been developed to 
classify and identify these potential threats. Threat identification is an extremely 


155 



difficult process to model, as real-world threat identification requires visual 
identification and observation. It is also difficult to model because the 
programming is complex, and generally revolves around a single threat 
characteristic or activity, and in the real world, variations on attack methods and 
concentration of assets are used which would make modeling extremely difficult, 
requiring substantial hardware, software, funding, and time to complete. This 
makes it well outside the scope of this particular project. 

All of the above issues could be addressed to create a higher fidelity model, 
potentially providing better data to the Program Managers. Additional topics for follow- 
on work are provided below. 

C. RECOMMENDED FOLLOW ON WORK 

The following section provides summary recommendations for follow-on efforts 
that could leverage the research, findings and artifacts from this project to benefit future 
interoperability solution and UAS- fleet integration. 

1. Use an Engagement Model for Mission Phase 3 

An area of analysis that could not be addressed in our model was the “end game” 
where targets identified as threats would be prosecuted with either non-lethal or lethal 
means. This effort required definition of tactics, ROE, analysis of weapons (including 
weapon-target pairing and stand-off range), and the decision chain required to support 
direct action. Recommend detailed engagement modeling to explicitly assess the link 
between interoperability and engagement metrics, such as probability of kill. 

2. Rebuild the NSS Model to Combine SOS Alternatives for Assessment of 

Cumulative Effectiveness 

As previously stated, the model was not designed to support the cumulative effects 
associated with the employment of both Alternatives 1 and 2, or 1, 2, and 3. The research 
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findings led to the observation that it may not be beneficial to implement Alternative 2 
(dual TCDL channels) without also implementing Alternative 1 (communication li nk 
between the FSCS and CIC) to integrate and exploit the airborne data. By combining 
these alternatives, greater interoperability improvements may be achieved than by 
incorporating either alternative as a stand-alone effort. 

3. Use Experimentation or Live Demo to Confirm CONOPS, 

Operational testing of Alternatives 1 and 2 could be performed as part of a Fleet 
Exercise at relatively low cost. One of the LCS ships already has two TCDL channels 
available, but only operates with one channel active. Providing a mini TCDL terminal to 
the MH-60R and doing a temporary ship alteration (SHIPALT) to open up the second 
TCDL channel, as well as wiring the FSCS video display into CIC could be with minimal 
time and cost impact to support a Fleet Exercise for the LCS ship deployed with both Fire 
Scout and MH-60R. This effort would require significant coordination, but could support 
a Fire Scout and MH-60 interoperability demonstration exercise that is currently 
scheduled for FY11. 

4. Perform Statistical Analysis on Model Results 

More detailed analysis of the model and simulation results is for an increased the 
level of confidence in the results that supports a resource decision. Recommend 
sensitivity analysis to ensure that the “Bang for the Buck” results are valid. 

5. Perform Market Research to Refine the WBS for More Accurate Cost Estimation. 

A WBS was developed for each alternative based on available and historical 
information. Additional coordination with the LCS ship community could clarify and 
optimize the baseline WBS, which could then lead to a more detailed cost analysis for 
Alternatives 1 and 2. Alternative 3 also requires optimization of the WBS, as well as 
market research on available communications systems that support the TCDL data 
formats (Alterative 3 A) and subsystems that have increased number of UHF data 
channels to support control of the Fire Scout sensor suite (Alternative 3B). Definition of 
these systems (along with definition of their interface to parent aircraft systems and 
software) supports definition of the baseline WBS and would provide a more robust cost 
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estimate, one that provides an assessment of the probability of program success based on 
a given funding level, as opposed to a point estimate. 

APPENDIX A - FUNCTIONAL DECOMPOSITION 


Through the use of CORE, an EFFBD was created for specific Operational Activities 
and Functions. A simple, clear description of the information flows was essential to 
ensuring the completeness and accuracy of the system design going forward. The 
Operational Nodes and Operational Information needed to execute the operational 
activities, or functions, were identified through the development and use of an 
Information Exchange Requirements (IER) matrix and informal input/output trace 
diagrams. The functions were tied to Operational Nodes using the CORE “performed 
by ” relationship, and Operational Infonnation was related with inputs, outputs, and 
“triggered by” relationships. (An important feature of the CORE tool, when developing 
an architecture, is the embedded schema for defining relationships within the model/ 291 
While this feature highly constrains the definition of architecture component interactions 
and data/information exchanges, it also ensures consistency and ease of use, stabilizing 
the application of architecture modeling and analysis for the SE process. ) Interface 
definition and management concerns for this project include: 

• Defining and establishing interface specifications 

• Identifying preferred and discretionary interface standards 

• Providing justification for selection of interface standards 

• Understanding the certifications and tests applicable to each interface or standard. 

• Developing functional and physical architectures 

• Supporting maintenance of system requirements and specifications over the life of 
the intended product, including reuse for future product upgrades and 
enhancements. 

Through the MBSE approach and use of CORE, the project team gained critical insight 
into the interaction of all components. Together, MBSE and CORE provide a process and 
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tool for the generation of a complete, consistent, and executable systems design and 
specification. The following 48 (activity diagram) and Figure 49 (N2 diagram) provide 
samples of the CORE modeling efforts in the area of the “Discriminate Contacts” 
function, which help define and communicate the activities and information exchange 
requirements for this function. 



Figure 48: Activity Diagram (CORE) for 'Discriminate Contacts' Function 
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Figure 49: N2 Diagram (CORE) for ’Discriminate Contacts' Function 


The functional architecture expressed the detailed functional, interface, and 
temporal aspects of the system that were essential to gain sufficient insight and to 
communicate unambiguously the behavior of the system in its intended operational 
environment. The development of a functional architecture and definition of system 
alternatives should evolve incrementally with stakeholder requirements and the physical 
architecture to ensure that the appropriate functions and interfaces are identified. This 
analysis may utilize structured or object oriented methods, or a combination thereof, 
along with associated and proven notations such as Integration Definition for Function 
Modeling (1DEF0), Enhanced Functional Flow Block Diagram (EFFBD), Department of 
Defense Architecture Framework (DODAF), and Systems Modeling Language (SysML) 
tools. It is anticipated that an automated tool such as CORE, by Vitech Corporation, will 
be utilized to assist in development and management of the system requirements and 
architecture products needed in support of the SE and acquisition processes. 

For this project the Functional Architecture analysis and decomposition efforts provided 
the following system information: 

• Description of the contributing systems’ functionality, interfaces and interactions 
necessary to accomplish the mission scenario 

• Existing and proposed system characteristics as a reference for modeling and 
analysis 

• Entity Relationship Diagrams, Activity and Functional Flow Diagrams and N2 
Diagrams used to specify integration / interoperability requirements 

Artifacts produced through use of CORE and PowerPoint aided the project team in 
understanding the current systems configurations, capabilities (and capability gaps), as 
well as assisting in identification of viable alternatives for achieving increased 
interoperability in this mission area. Artifacts included: 


• Activity diagrams 

• N2 diagrams 

• Sequence diagrams 
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• Preliminary Integrated Architecture (CORE Model) 

• DoDAF views to include at minimum: OV-1, SV-5 

• Information Exchange Requirements (IER) Diagrams 

• Functional Flow Block Diagrams (FFBD) 

A secondary objective of the project was to explore the use of architecture artifacts as 
direct input to the NSS modeling effort. The complexity of the two tools proved to make 
it difficult, and therefore prohibitive, to directly map SE artifacts into the M&S process 
for warfare effectiveness analysis. Regardless, the architecture developed in CORE is an 
artifact that can be re-used for SE follow-on work to benefit requirements engineering 
and management. 
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APPENDIX B - NSS SCREEN SHOTS 

This appendix provides a sample of NSS Screen Shots to illustrate the structure and 
content of the modeling tool. From and SE perspective, it was critically important to 
specify the inputs and outputs to align with the SE process and artifacts. 



Figure Bl: NSS Database 


162 
































Figure B2: NSS Input Mode: Comms Passthrough 
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Figure B4: NSS Input Mode: Neutral Ships 
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Figure B5: NSS Input Mode: Regions and Tracks 



Figure B6: NSS Input Mode: Sortie Schedule 
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Figure B7: NSS Instance Properties: VTUAV 
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